From: SF/projects/mingw n. l. <min...@li...> - 2011-06-07 07:26:34
|
Bugs item #3305053, was opened at 2011-05-20 12:56 Message generated for change (Comment added) made by fabian_deb 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: Fabian Greffrath (fabian_deb) Date: 2011-06-07 09: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 19: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 09: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 09: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 11: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 13: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 10: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 22: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 16: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 15: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 14: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 14: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 10: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 20: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 10: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 14: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 14: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 |