Mail Archives: cygwin/2005/08/31/10:19:29
On Wed, 31 Aug 2005, Antony Baxter wrote:
> Igor,
>
> > I haven't had a chance to debug this properly, but from the first
> > glance at the code, it's actually weirder than that. The "U" in the
> > debug output means that pine tries to use the user's preferred shell.
> > If SHELL is undefined, pine tries to use /bin/csh (yes, "csh" -- don't
> > ask me why). In system mode, it uses /bin/sh, like all normal apps.
> >
> > Anthony, do you have the tcsh package installed? If not, that may be
> > your problem. Just for kicks, if you don't have a /bin/csh, try "ln
> > /bin/sh /bin/csh" (yes, I know it won't work with csh syntax), and see
> > if that makes pine work for you.
> >
> > Another thing to try is to export SHELL from bash. Just say "export
> > SHELL" with the current value (i.e., /bin/bash).
>
> Yup, both of those solutions work, though I'm sticking with exporting
> SHELL for portability. I don't have tcsh installed.
Right. I've asked for the new pine dependencies to be uploaded -- once it
propagates to the mirrors, installing pine will also install tcsh.
> > As for fixing this, there are two options -- one is to send a patch
> > upstream (who uses /bin/csh nowadays anyway?), and another is to make
> > "pine" depend on "tcsh".
>
> Out of interest, is it correct behaviour for Bash to return a value for
> SHELL even though it hasn't been explicitly set? Presumably this is
> handled by Bash itself in such a way that getenv doesn't see it; is that
> in itself a bug?
Shells have two categories of variables: internal and exported (there are
official shell category names for them, but they escape me at the moment).
The exported variables are propagated to child processes; the internal
ones aren't. Usually, setting a variable in the shell puts it in the
"internal" category, unless the user explicitly "export"s it.
Bash sets "$SHELL" automatically, presumably to indicate what shell the
user is currently running. The fact that it doesn't export it may or may
not be a bug. I'd say "not", since, if the user *does* have SHELL set in
the bash shell's parent environment, you wouldn't want any process
launched from bash to see "/bin/bash" as the value of the SHELL instead of
whatever the user put there originally.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
--
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/
- Raw text -