At 05:37 AM 10/2/2001, David Starks-Browning wrote: >If your non-Cygwin application (like Emacs) requires HOME be set in a >non-Cygwin way, then don't start emacs from your Cygwin bash shell. > >If you must invoke your emacs command from the Cygwin bash shell, you >could put the emacs command in a windows .bat file, and invoke that >file from Cygwin bash. In the .bat file, your HOME variable should be >set the way Emacs needs it. > >Hope this helps.
Let me clarify the problem. Emacs doesn't care what $HOME is set to, it cares what path it sees on the command line. The issue is that bash, by default, expands ~/filename to a posix-style path, resulting in commands like "emacs /c/users/matt/.bashrc", which doesn't work for any non-Cygwin program. Saying "don't run non-Cygwin programs from bash" isn't a thrilling answer; an interactive shell is most useful when you can use it as your shell for *everything*. There is a half-hearted workaround, which is to reset HOME to a win32-style path in .bashrc so that ~/.bashrc expands to c:/users/matt/.bashrc (since cygwin programs understand win32-style paths, there's little reason not to do this), but it breaks bash's completion. That's the real bug I was asking about. It's not clear to me why bash should be able to expand posix-style paths but not win32-style paths. I suppose another workaround is to define a shell function that turns "emacs filename" into "emacs `cygpath -w filename`", converting all names back to win32-style paths before emacs ever sees them, but having to do this for every non-cygwin application I ever run from the shell is going to get tedious. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
