Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Wed, 31 Aug 2005 10:18:58 -0400 (EDT)
From: Igor Pechtchanski <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: Antony Baxter <antony_baxter AT yahoo DOT co DOT uk>
cc: cygwin AT cygwin DOT com
Subject: Re: 1.5.18: Problem launching URLs from Pine
In-Reply-To: <20050831140946.49226.qmail@web86902.mail.ukl.yahoo.com>
Message-ID: <Pine.GSO.4.63.0508311012140.3395@slinky.cs.nyu.edu>
References: <20050831140946 DOT 49226 DOT qmail AT web86902 DOT mail DOT ukl DOT yahoo DOT com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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/