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: 1.5.18: Problem launching URLs from Pine


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@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.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/


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