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

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

On Thu, 14 Oct 2004, Dave wrote:

> [snip]
> > 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).

Huh?  Why is this buggy?  Most shells will look in $HOME for the rc
scripts.  FWIW, you don't have to actually *cd* to $HOME for this.

> >> >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 scripts.

Well, I think the base-files maintainer would be happy to coordinate on
adding an extra variable check to /etc/profile so that it doesn't cd to
$HOME...

> >> 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.

It would certainly *look* nasty.

> Having an env variable set for a startup script to cd to seems a nicer
> way to handle things.

I agree.

> 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.

Heh?  Just make the variable name strange enough to avoid accidental
clashes...

> 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.

Sure.  'bash -c "exec -l $PROG $ARGS"'. :-)
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/