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.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers