From: SF/projects/mingw n. l. <min...@li...> - 2011-05-24 20:50:08
|
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: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Fabian Greffrath (fabian_deb) Assigned to: Nobody/Anonymous (nobody) Summary: MSYS's vim crashes in cmd.exe 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-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 |