Default HOME environment

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

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.

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.

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.

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.

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.

> 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

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.

> 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...

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.

> 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?

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.

> 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.

> 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. ;)

> 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?

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.

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!

> 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>

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

> We've already established a default via /etc/profile.

Right, but this is only executed for *login* shells. Remember, the problems I experience occure with binaries started from the cmd.exe prompt. Everything is fine in MSYS.

IMHO, vim et al are UNIX programs, they rely on specific environment variables which are essential for a UNIX system and the UNIX-compatibility library they are built against should provide fallbacks for these variables if the original environment fails to do so.

I believe MSYS should not rely and depend on environment variables set in Windows at all. For example, see what happens when you do the following on a cmd.exe prompt:
> set TEMP=
> set TMP=
> sh -c "mktemp"

I have to admit, the more I investigate the crashing vim issue, the less I understand what's really going on. After all, maybe it's *not* the missing HOME variable that is directly involved in the crash, but it's merely the fact that vim takes a completely different code path depending on the HOME variable being set or not. I have added some private printf()s around the spurious call_shell() function in line ~5600 of the os_unix.c file in the vim source code and they aren't even executed if HOME is set. Furthermore I have modified the string passed over to the shell to include something like "export HOME=. ;" at the beginning, but it didn't help either.

In the end it turns out that sh.exe crashes in vim for *some* reason and takes vim with it, and that the affected code is simply circumvented by setting the HOME variable.

Cesar is this worth further investigation by you?