[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] whatnow brittle wrt. $SHELL

From: David Levine
Subject: Re: [Nmh-workers] whatnow brittle wrt. $SHELL
Date: Sun, 22 Jul 2012 12:41:41 -0500

az wrote:

> whatnow cooks up strings for executing external commands,
> and then feeds these strings to popen or system.  these
> command strings rely on $SHELL being present - and if that
> is not the case, then we get weird error messages ("sh: -c
> not found" or similar).
> the attached trivial patch uses setenv() with overwrite=0
> to achieve that.

Patch applied, thanks very much.

I added a test of that (unset SHELL) to whatnow/test-ls.
But it doesn't seem to catch the problem on Linux.  It looks
like its system() always sets SHELL to /bin/bash if it was
unset.  If it was set to anything (even empty), it doesn't
change it, but it uses /bin/bash to execute the command.
(That's how it's documented, assuming /bin/bash replaces
/bin/sh).  So what eventually gets executed is, e.g.,

  /bin/bash -c '/bin/bash -c ls'

which works though is a bit wasteful.  And "/bin/bash -c -c ls"
works, too, so it doesn't catch the empty $SHELL.

Looking at the documentation for POSIX system(), it always
executes its argument by invoking sh -c.  Its only mention
of SHELL says that it "is discouraged".  So, should we
remove the "$SHELL -c" entirely?

popen() is documented and behaves the same way.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]