Re: bash 2.04 can't complete ~/name if $HOME set to c:/users/foo?

[Matt Landau <matt at atg dot com>]

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/