Thu 15 Dec 2016 06:21:55 PM UTC, comment #22:
Pushed http://hg.octave.org/mxe-octave/rev/b73fe78f73c3
|
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.
|
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
|
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
So I do not think we can rely on HOMEDRIVE/HOMEPATH being set to the proper values
|
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.
|
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
|
Thu 08 Dec 2016 03:47:05 PM UTC, comment #16:
Perhaps this:
(file #39175)
|
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.
|
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 '\'
|
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.
|
Wed 07 Dec 2016 09:20:44 PM UTC, comment #12:
I am seeing identical results as comment #6.
cmd.com:
octave.bat
cmdshell.bat
cmdshell.bat -> octave-cli -Wq
cmdshell.bat -> octave-gui -Wq
cmdshell.bat with --login -i (comment #7)
cmdshell.bat with --initfile... (comment #6)
|
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?
|
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)
|
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.
|
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
|
Wed 07 Dec 2016 04:05:56 PM UTC, comment #7:
I have changed mine to:
%OCTAVE_HOME%\bin\bash.exe --login -i
|
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
|
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.
|
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.
The same trick might be used with OCTAVE_HOME
|
Sun 04 Dec 2016 10:24:30 PM UTC, comment #3:
Now that I think about it, might be as simple as adding
to cmdshell.bat
I think this is a better approach, since some other programs/scripts might also rely on the HOME variable being set.
|
Sun 04 Dec 2016 07:40:06 PM UTC, comment #2:
Looks like a call to this may be the right call:
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.
|
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?
|
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
Might also be related to this old bug #41131
|