This is the mail archive of the
mailing list for the Cygwin project.
Re: Use of SHELL env var by login
Andrey Repin wrote:
In the absence of /etc/passwd, setting SHELL is the right way to set your login
One of the right ways, I'd say.
If your aim is the integration of both environments, you MAY set variables,
but if you then start a login shell, they may be voided by the startup scripts.
I would advise using "more other" ways to configure Cygwin, i.e. using SAM DB
Windows *doesn't* use "SHELL" to set your command line, it uses
COMSPEC. So setting SHELL won't do MS programs any good. I set mine for
the benefit of some non-MS programs that ran windows natively so I could
have an easier time in some of my own scripting. The form C:/bin/bash.exe
was *NOT* set by cygwin prompting me to set it -- since it cygwin wanted a
windows path it would only have accepted C:\bin\bash.exe. If it wanted a
non-windows, pure-posix-like path, it would have complained about referring
to /c as "C:".
It's the unsupported "middle-ground" path that works in
win32 and cygwin -- but my cygwin is install @ '/' not /c/ (though they
end up at the same point) -- I mention the C: drive primarily for windows
programs (if they are on another drive, the path /bin/bash.exe is processed
as being on the "current drive", so in program like the _windows_
_versions_ of 'vim/gvim', that "cd" to the same directory as the file you are
editing, also end up changing drive letters (a network drive in my setup)
where /bin/bash doesn't work (as /bin/bash would only work when drive 'C' is
current). You *can* set COMSPEC to something other than "cmd.exe", but I
would not -- since some windows program depend on COMSPEC to be cmd.exe ( :-( ).
Setting SHELL will have no effect on Microsoft windows program -- it may
on some non-MS programs running on windows, but i've not found it provided
sufficient benefit for the troubles.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple