Mail Archives: cygwin/2001/10/02/10:34:30
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/
- Raw text -