bugGNU Octave - Bugs: bug #49765, Windows CLI version octave tries...

 
 

bug #49765: Windows CLI version octave tries to write history to C:\

Submitter:  kire pudsje <kpc>
Submitted:  Sun 04 Dec 2016 06:35:42 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  lostbard
Originator Name:  kpc Open/Closed:  * Closed
Release:  * 4.2.0 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 15 Dec 2016 06:21:55 PM UTC, comment #22: 
John Donoghue <lostbard>
Group Member
Wed 14 Dec 2016 06:33:50 AM UTC, comment #21: 

Maybe also apply the HOME and 8.3 conversion to octave.bat?
For the rest I think this bug can be closed, thanks.

kire pudsje <kpc>
Tue 13 Dec 2016 01:23:03 PM UTC, comment #20: 

Pushed http://hg.octave.org/mxe-octave/rev/8f71549f53b9

Sets HOME to userprofile to be consistant with running the octave shortcut.

bash is put into interactive mode as well

John Donoghue <lostbard>
Group Member
Fri 09 Dec 2016 05:38:37 AM UTC, comment #19: 

Modifying the HOMEPATH env variable has apparently been a conscious choice in cygwin. See the following comment, taken from winsup/cygwin/uinfo.cc

 399       /* Use Cygwin home as HOMEDRIVE/HOMEPATH in the first place.  This
 400          should cover it completely, in theory.  Still, it might be the
 401          wrong choice in the long run, which might demand to set HOMEDRIVE/
 402          HOMEPATH to the correct values per Windows.  Keep the entire rest
 403          of the code mainly for this reason, so switching is easy. */


So I do not think we can rely on HOMEDRIVE/HOMEPATH being set to the proper values

kire pudsje <kpc>
Thu 08 Dec 2016 10:27:06 PM UTC, comment #18: 

The problem then is that HOME resolves to /home/USERNAME, which is ok, except that when running octave on its own, it uses the user profile.


John Donoghue <lostbard>
Group Member
Thu 08 Dec 2016 08:03:42 PM UTC, comment #17: 

@lostbard
Personally I prefer if cmdshell.bat did not override HOME.
Just let the login init-scripts set it according to the MSYS convention, but that's just me :)

Anyway the file cmdshell.bat should probably be renamed to better reflect that it's actually starting a bash.exe shell not Windows' cmd.exe shell.

We could even have two files: shell-cmd.bat and shell-bash.bat, one launches %COMSPEC% and the other bash.exe

Amro <amro_octave>
Thu 08 Dec 2016 03:47:05 PM UTC, comment #16: 

Perhaps this:


(file #39175)

John Donoghue <lostbard>
Group Member
Thu 08 Dec 2016 01:44:06 PM UTC, comment #15: 

Either way, since cmdshell.bat launches a Bash shell and not Octave itself, I think it should be started as an interactive/login shell, that way it processes startup scripts in /etc/profile first followed by user-defined ones (like  ~/.bash_profile, ~/.bash_login, ~/.profile, and ~/.bashrc).

This is similar to what default shortcuts of Cygwin or MinGW/MSYS on Windows do anyway.

It should be mentioned that $HOME is set by /etc/profile initialization script, along with $PS1 and creating ~/.inputrc to make a better shell experience.

Amro <amro_octave>
Thu 08 Dec 2016 01:21:11 PM UTC, comment #14: 

funnily enough, if I set some other variable in the cmdshell.bat file to HOMEPATH,

say set VVV=%HOMEPATH%

when looking at the variables in bask, VVV is correct, but HOMEPATH is '\'

 

John Donoghue <lostbard>
Group Member
Wed 07 Dec 2016 09:23:39 PM UTC, comment #13: 

Ok, thanks. Sorry for missing that detail. I agree this should be pursued primarily to fix the environment variables to ensure that this wrong environment isn't passed in to Octave.

Mike Miller <mtmiller>
Group Member
Wed 07 Dec 2016 09:20:44 PM UTC, comment #12: 

I am seeing identical results as comment #6.

cmd.com:

echo %HOMEDRIVE%
C:
echo %HOMEPATH%
\Users\kire
echo %HOME%
%HOME%


octave.bat

getenv('HOMEDRIVE')
ans = C:
getenv('HOMEPATH')
ans = \Users\kire
getenv('HOME')
ans =


cmdshell.bat

echo $HOMEDRIVE
C:
echo $HOMEPATH
\
echo $HOME


cmdshell.bat -> octave-cli -Wq

getenv('HOMEDRIVE')
ans = C:
getenv('HOMEPATH')
ans = \
getenv('HOME')
ans =


cmdshell.bat -> octave-gui -Wq

getenv('HOMEDRIVE')
ans = C:
getenv('HOMEPATH')
ans = \
getenv('HOME')
ans =


cmdshell.bat with --login -i (comment #7)

echo $HOMEDRIVE
C:
echo $HOMEPATH
\
echo $HOME
/home/kire


cmdshell.bat with --initfile... (comment #6)

echo $HOMEDRIVE
C:
echo $HOMEPATH
\
echo $HOME
/home/kire


kire pudsje <kpc>
Wed 07 Dec 2016 08:30:34 PM UTC, comment #11: 

Oh. Can we verify that? Kire - what are the values of HOMEDRIVE and HOMEPATH set to in Octave when this fails, when you undo whatever changes you've made locally?


getenv ("HOMEDRIVE")
getenv ("HOMEPATH")


Mike Miller <mtmiller>
Group Member
Wed 07 Dec 2016 08:28:21 PM UTC, comment #10: 

I'm willing to test it

I believe though, that the original report is due to HOMEDRIVE and HOMEPATH being set already (not sure if bash defaults, or something else?) and so octave is just using what it was given (comment #6)

John Donoghue <lostbard>
Group Member
Wed 07 Dec 2016 08:20:32 PM UTC, comment #9: 

Ok, this has evolved into how to get bash to initialize the HOME environment variable correctly.

Is anyone interested in testing a patch to try to get the user's home directory from the operating system even when HOME and HOMEDRIVE and HOMEPATH are not in the environment at all? Because we already do that on GNU systems and I think Octave should behave symmetrically on other systems. I am willing to write a patch if someone is willing to build and test.

Mike Miller <mtmiller>
Group Member
Wed 07 Dec 2016 08:20:21 PM UTC, comment #8: 

Changing it per comment #7, sets the HOME to /home/username which does stop it from crashing, however then is using a different place for the octave_history

John Donoghue <lostbard>
Group Member
Wed 07 Dec 2016 04:05:56 PM UTC, comment #7: 

I have changed mine to:
%OCTAVE_HOME%\bin\bash.exe --login -i

Amro <amro_octave>
Tue 06 Dec 2016 04:04:39 PM UTC, comment #6: 

On my win64 Wndows 10 machine:

running the shortcut for the shell.

HOMEDRIVE=C:
HOMEPATH='\'


Running cmd.exe,

HOMEDRIVE=C:
HOMEPATH=\Users\johnd


When running octave from its shortcur rather than from the Bashsell shortcut, and octave is set the same as cmd.exe


It also appears that bash is not using the /etc/profile file from the mxe install.

If I change the bashshell script to:
%OCTAVE_HOME%\bin\bash.exe --init-file %OCTAVE_HOME%\etc\profile

I get the same path as cli.exe






John Donoghue <lostbard>
Group Member
Mon 05 Dec 2016 01:41:28 AM UTC, comment #5: 

Sorry for posting a lot. Thought about it again. Only set HOME when not already defined. Whether HOME has already been defined or userprofile is used, in any case remove spaces when necessary.


if not defined HOME (
  set HOME=%UserProfile%
)
if not "%HOME: =_space_%" == "%HOME%" (
  for %%I in ("%HOME%") do set HOME=%%~sI
)


kire pudsje <kpc>
Sun 04 Dec 2016 11:27:03 PM UTC, comment #4: 

And to avoid problems with people using spaces in filenames, obtain the short dos form of the directory.
Long filenames (>8 characters) without spaces will be kept normal, as to avoid ugly filenames.


if "%UserProfile: =_space_%" == "%UserProfile%" (
  set HOME=%UserProfile%
) else (
  for %%I in ("%UserProfile%") do set HOME=%%~sI
)


The same trick might be used with OCTAVE_HOME

kire pudsje <kpc>
Sun 04 Dec 2016 10:24:30 PM UTC, comment #3: 

Now that I think about it, might be as simple as adding


set HOME=%UserProfile%


to cmdshell.bat
I think this is a better approach, since some other programs/scripts might also rely on the HOME variable being set.

kire pudsje <kpc>
Sun 04 Dec 2016 07:40:06 PM UTC, comment #2: 

Looks like a call to this may be the right call:


SHGetKnownFolderPath (FOLDERID_Profile, 0, 0, &str);


If someone is willing to test a patch (build mxe-octave, install, and test), we can see if adding this to oct-env.cc helps here.

Mike Miller <mtmiller>
Group Member
Sun 04 Dec 2016 07:32:49 PM UTC, comment #1: 

Attempting to write the history file to the root directory is not a bug in and of itself. But maybe it is a bug that there is no fallback mechanism for getting the user's home directory, or that it's not working in this scenario, on Windows.

Having no HOME variable on a GNU system falls back to checking the pwent database. On Windows, it is supposed to check HOME, followed by HOMEDRIVE and HOMEPATH. If none of these environment variables are set, is there a system call Octave can make to get the user's home directory?

Mike Miller <mtmiller>
Group Member
Sun 04 Dec 2016 06:35:42 PM UTC, original submission:  

Starting the cmdshell.bat then starting "octave -Wq" and pressing Ctrl-D to exit fails to write the history.
Might be caused by the HOME-variable not being set in the terminal
Setting the HOME variable by hand (export HOME=....) causes the file to be saved in the $HOME directory.
Using the zip-file on windows 10

bash-3.1$ octave -Wq
bash-3.1$ octave:1>
error: writing file 'C:\.octave_hist': Permission denied
error: ignoring const octave::execution_exception& while preparing to exit

Might also be related to this old bug #41131

kire pudsje <kpc>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #39175:  cmdshellfixes2.patch added by lostbard (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by amro_octave (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by kpc (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-12-15 lostbard StatusNeed Info Fixed
        Assigned toNone lostbard
        Open/ClosedOpen Closed
    2016-12-08 lostbard Attached File- Added cmdshellfixes2.patch, #39175
    2016-12-04 mtmiller StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code