[MinGW-notify] [ mingw-Bugs-3305053 ] Default HOME environment

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #3305053, was opened at 2011-05-20 06:56
Message generated for change (Comment added) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3305053&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
Group: Known Feature
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fabian Greffrath (fabian_deb)
Assigned to: Cesar Strauss (cstrauss)
Summary: Default HOME environment

Initial Comment:
Hi,

I have MSYS's /bin directory in my PATH variable. If I try to start vim from cmd.exe, it crashes without any output. Is this expected behaviour, since cmd.exe is not a "real" terminal or is this indeed a bug? Anyway, a clarifying error message would be better than plain crashing if started from the wrong environment.

Regards,
Fabian

----------------------------------------------------------------------

>Comment By: Earnie Boyd (earnie)
Date: 2011-06-07 13:59

Message:
We've already established a default via /etc/profile.  If we do anything in
the runtime it will mimic that.

if [ -z "$USERNAME" ]; then
  LOGNAME="`id -un`"
else
  LOGNAME="$USERNAME"
fi

# Set up USER's home directory
if [ -z "$HOME" ]; then
  HOME="/home/$LOGNAME"
fi

----------------------------------------------------------------------

Comment By: Fabian Greffrath (fabian_deb)
Date: 2011-06-07 03:48

Message:
> Zsh falls back to %USERPROFILE% and - if this is unset -
> to an empty string.

And I think this is actually the correct behaviour! According to the bash
reference manual [1]:
"[...] the tilde is replaced with the value of the HOME shell variable. If
HOME is unset, the home directory of the user executing the shell is
substituted instead."

On Windows systems, the home directory of the user executing the shell is
given by the %USERPROFILE% variable.

The following quote from Bash Hackers [2] confirms this assumption:
"If the given user doesn't exist (or if his home directory isn't
determinable, for some reason), it doesn't expand to something else, it
stays what it is. The requested home directory is found by asking the
operating system for the associated home directory for <NAME>."

If the operating system in question is Windows, the home directory will be
given by %USERPROFILE%. If this variable does not exist either, do not
expand at all (i.e. zsh returns an empty string in that case, which I'd
consider safe).

Reading further:
"To find the home directory of the current user (~), Bash has a
precedence:
-    expand to the value of HOME if it's defined
-    expand to the home directory of the user executing the shell
(operating system)
That means, the variable HOME can override the "real" home directory, at
least regarding tilde expansion."

So what we are doing in MSYS is to override the "real" home directory of
the user as returned by the operating system (i.e. %USERPROFILE%) with the
$HOME variable pointing to /home/<user> in the MSYS directory. But we
definitely need to provide a fallback for tilde expansion when this
variable is unset.

Thank you very much for your attention. ;)

[1] <http://www.gnu.org/software/bash/manual/bash.html#Tilde-Expansion>
[2] <http://wiki.bash-hackers.org/syntax/expansion/tilde>

----------------------------------------------------------------------

Comment By: Fabian Greffrath (fabian_deb)
Date: 2011-06-07 03:26

Message:
I think I have finally found the culprit to the crashing vim issue: During
start up, vim runs a shell to gather its locally installed plugins via the
following call

call_shell (unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo "$1";
shift; done }; vimglob >/tmp/v368869/0 ~/.vim/plugin/**/*.vim, 18)

which can be found in os_unix.c:5597 in the vim sources. As you can see,
it passes a tilde to the shell, which it tries to expand but cannot since
$HOME is undefined! If I remove sh.exe from the PATH, vim simply fails to
call the shell and proceeds with minor error messages. As soon as I add
MSYS sh.exe back to the path, vim crashes.

I have tried with another shell, i.e. sh.exe from UnxUtils which is a zsh
and in this case it works, even with HOME unset. It seems that zsh falls
back to $HOME=%USERPROFILE% when $HOME is unset. However, also unsettting
USERPROFILE still does not lead to crashing vim.

Now comes the bonus question: What should ~ expand to if HOME is unset?
Currently, MSYS sh.exe falls back to "/" which might be the cause of the
problem with vim. Zsh falls back to %USERPROFILE% and - if this is unset -
to an empty string. I think this should also be considered for MSYS sh.exe!

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-06-06 13:19

Message:
Maybe /home/($USERNAME).

But maybe we also need to modify white space to an _ in the value.  I'll
let Cesar decide.  I modified the Summary title.

----------------------------------------------------------------------

Comment By: Fabian Greffrath (fabian_deb)
Date: 2011-06-06 03:08

Message:
> Well then how about setting it to TEMP, if that exists, or TMP?

Ah, forget it. As soon as you are logged in, this variable gets a per-user
value and points to some directory beneath %USERPROFILE% and may thus
contain spaces as well. :/

Isn't there any valid alternative for a fallback directory in case of an
undefined $HOME?

----------------------------------------------------------------------

Comment By: Fabian Greffrath (fabian_deb)
Date: 2011-06-03 03:45

Message:
> Setting HOME to some arbitrary value isn't going to happen and especially
> to `.'. If you don't know why, try it out yourself.

Well then how about setting it to TEMP, if that exists, or TMP?

The variable and the corresponding directory are almost certain to exist
on a Windows system. The variable value can be expected to be constant over
a system's lifetime, so it's not an arbitrary directory. And it should get
cleaned up from time to time anyway. ;)

----------------------------------------------------------------------

Comment By: Fabian Greffrath (fabian_deb)
Date: 2011-05-27 05:39

Message:
> On your NB point, can you write it up in the www.mingw.org/wiki and add a
> link to it in the www.mingw.org/wiki/HOWTO document? TIA.

> No, I think the NB is a HOWTO and needs a separate page. However,
> Getting_Started needs to mention both the FAQ and the HOWTO pages.

All done.

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-05-25 07:46

Message:
www.mingw.org->Documentation->MinGWiki Pages

Re: Getting_Started,
No, I think the NB is a HOWTO and needs a separate page.  However,
Getting_Started needs to mention both the FAQ and the HOWTO pages.

----------------------------------------------------------------------

Comment By: Fabian Greffrath (fabian_deb)
Date: 2011-05-25 04:53

Message:
> Setting HOME to some arbitrary value isn't going to happen and especially
> to `.'. If you don't know why, try it out yourself.

Still better than a crashing application, IMHO.

> On your NB point, can you write it up in the www.mingw.org/wiki and add
a
> link to it in the www.mingw.org/wiki/HOWTO document? TIA.

Yes, I'd love to. How do I add it to the WIKI? I am already registered but
could not find a button to modify content.
Don't you think it would better fit in the "Gettnig started" section, BTW?

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-05-24 16:50

Message:
Setting HOME to some arbitrary value isn't going to happen and especially
to `.'.  If you don't know why, try it out yourself.

On your NB point, can you write it up in the www.mingw.org/wiki and add a
link to it in the www.mingw.org/wiki/HOWTO document?  TIA.

----------------------------------------------------------------------

Comment By: Fabian Greffrath (fabian_deb)
Date: 2011-05-24 10:40

Message:
> It is set in an MSYS environment. It isn't set by the DLL.

Sure, but if the DLL could take care that an empty HOME variable is set
to, say, ".", then a large number of corner cases (even if actually
unsupported) could be fixed - and I think this little fix will not do any
harm to the other supported use cases of the DLL.

> The
> recommendation is to set the HOME variable in your Windows environment
if
> you wish to use MSYS from Windows cmd.exe.

To be honest, until now I could not find this recommendation *anywhere*.

> I have HOME set in my Windows environment which ViM uses to
> find the .vimrc file.

I have done the same, pointing to my MSYS HOME directory.

NB:
For the curious, I have not set the variable globally via the Windows
control panel, but via some kind of rc-script for cmd.exe, i.e. a batch
file in my Windows home directory. In order to have this batch file run
whenever cmd.exe is invoked, add it to the "AutoRun" key in
[HKEY_CURRENT_USER\Software\Microsoft\Command Processor]. When I had HOME
set globally then unrelated software, e.g. VirtualBox, spuriously begins to
look there for its settings...

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-05-24 09:52

Message:
It is set in an MSYS environment.  It isn't set by the DLL.  The
recommendation is to set the HOME variable in your Windows environment if
you wish to use MSYS from Windows cmd.exe.

Note, I use the native Windows version of vim distributed officially by
the ViM team.  I have HOME set in my Windows environment which ViM uses to
find the .vimrc file.

----------------------------------------------------------------------

Comment By: Fabian Greffrath (fabian_deb)
Date: 2011-05-24 08:45

Message:
> HOME is one of those essential variables required by *NIX systems.

This is the exact reason why I suggested to set it to a reasonable default
in MSYS if it is found to be empty in this bug report (which also got
immediately closed):
https://sourceforge.net/tracker/?func=detail&aid=3305192&group_id=2435&atid=102435

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-05-24 08:17

Message:
Thanks for the update.  HOME is one of those essential variables required
by *NIX systems.  It is one of the variables I happen to set in my Windows
environment.  ViM actually reads files from and writes files to the HOME
directory and I suggest you set HOME to some viable location on your disk
within your Windows environment.

----------------------------------------------------------------------

Comment By: Fabian Greffrath (fabian_deb)
Date: 2011-05-24 04:08

Message:
Actually, vim crashes in cmd.exe whenever the HOME variable is undefined.
For some reason, if HOME is unset in cmd.exe via "set HOME=", then
getenv("HOME") in any C-code fails, whereas it still returns a string of
length 0 (but at least succeeds) when run from bash.

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-05-23 14:42

Message:
Whether or not the MSYS dependent version of ViM is crashing from cmd.exe
or not isn't our concern.  The OP stated that it works from MSYS bash which
ends our need to provide support.

----------------------------------------------------------------------

Comment By: Shinobu Maehara (shinobu_maehara)
Date: 2011-05-23 04:48

Message:
If VIM actually crashes, then that is a bug in VIM, regardless of whether
that use case is supported or not. If it won't work, it should output a
diagnostic message. But a crash is always a bug, almost by definition,
hence this ticket shouldn't have been closed as invalid.

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2011-05-20 08:45

Message:
It is expected, with a reasonably high probability.

MSYS programs are not intended to be invoked from cmd.exe.  Some may work,
others will not.  YMMV, but either way, that usage is unsupported.

If vim is one of those that doesn't work for you, then too bad; it doesn't
work.  It does work when invoked as intended, from an MSYS shell.  Support
stops with telling you that's how you should run it.

----------------------------------------------------------------------

Comment By: Fabian Greffrath (fabian_deb)
Date: 2011-05-20 08:21

Message:
NB: If i start bash from cmd.exe and then start vim from the bash prompt,
it works.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3305053&group_id=2435

[MinGW-notify] [ mingw-Bugs-3305053 ] Default HOME environment

A native Windows port of the GNU Compiler Collection (GCC)

[MinGW-notify] [ mingw-Bugs-3305053 ] Default HOME environment