This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: tcsh and chere-0.3-1 (fwd)

>> From: Andrew Grimm
>> On Wed, Oct 13, 2004 at 07:02:13PM -0400, Christopher Faylor wrote:
>> >Actually, All shells which support -l seem to cd to the home directory.
>> >I'm not sure what the -l adds to the above since the above code just
>> >calls the shell again after cd'ing to the directory.
>> I think the purpose of that is to ensure that ~/.login (or whatever) gets
>> called to completely set up the shell's environment.  Normal shells don't
>> read in that file because they are assumed to inherit their environment
>> from the base login shell.

> cgf said:
> Aha.  I didn't know that this was something we were doing.

Yup. The -l makes sure the shell started from explorer reads the startup scripts
and sets its environment correctly.

> If that is the case then maybe we could get some coordination going and
> set a CYGWIN_CD_HERE environment variable or something and just have the
> login shell cd to the right directory automatically with the help of
> the /etc/* scripts.

This would work. Except where the user specific rc scripts expect to be in the
users home directory (which I think is buggy, but possible).

>> >It almost seems like you could just use ash to invoke the real shell in
>> >all cases.  That would be faster.
>> True, you could use any shell as the base login shell which exec's the
>> desired shell.  That has the benefit of always working.  However, that
>> approach will bypass the login-shell-specific config files for other shell
>> types.  For instance, "ash -" will load env vars from ~/.profile rather
>> than ~/.login which a tcsh user is unlikely to have set up to produce
>> identical results (for instance I like to put MANPATH in ~/.login but I
>> don't have a ~/.profile at all).  This would result in a "chere" shell
>> which will not behave quite like the user's regular shells, which are
>> spawned from a login shell of the same flavor.
>> Actually that appears to be another bug in the script:  chere should
>> invoke ash as "ash -" to start an ash login shell (I haven't tested this
>> though).

I suspected both these shells might have problems. Was just hoping they had some
undocumented behaviour (since the other shells are consistent). I also wasn't
sure if the login behaviour did anything extra, so didn't just ruin the startup

>> I think with most login shells the "cd $HOME" behavior is due to the way
>> the scripts are written in /etc (for example Cygwin's /etc/csh.login).
>> That is probably a good thing to have in the script, but it presents a
>> difficulty for this unusual application.

Thanks for the feedback.

I'm not sure that having a non-login shell run the startup scripts is the
correct thing to do. Mainly because you end up with a nasty command line
checking whether files are available. And this won't work with the passwd
runtime evaluation (is anyone using this? Or wanting to?) without even more
nasty quoting.

Having an env variable set for a startup script to cd to seems a nicer way to
handle things. Just not sure if this will break user specific and non-login
scripts. Should probably also enclose any cd behaviour in an "if [ `uname` ==
CYGWIN* ]" for people who like to share scripts between systems.

Do the tcsh/ash maintainers have any suggestions/preferences?

Does anyone know of a way to get a `-` at the start of $0? I believe this will
force all the shells to start as login shells and is the most generic solution.


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]