To answer a bunch of emails on this topic:
Ralph Corderoy says:
No `#'? How about just always send to the user's shell from the
password entry with a -c, as distinct from /bin/sh.
I guess I wasn't thinking of #, but if perl doesn't check for it it makes
me think it's not really useful to check for it (I mean, really, what
are you trying to do there?) Also, I think I'm with others ... what
is the advantage to using the user's shell here? Like Jerrad Pierce
said, /bin/sh seems to be the LCD here.
(As an aside ... didn't know there was a shell called Zoidberg! Hah!)
Valdis Kletniecks says:
The problem is that some people (at least in the Elder TImes) would have
their login shell set to /bin/csh but they'd want their scripty things done in
/bin/sh. (I used to do that myself, way back when csh had ! history and sh
didn't until it became bash).
Does anybody still do that?
Yeah, I still do that (and I guess I'm not the only one).
Paul Vixie says:
for that we have getenv('SHELL'), which is far more closely related to
the user's preferred command language than either their login shell or
the posix standard are going to be.
Is it? I always thought SHELL was set by the shell itself. My SHELL
is /bin/tcsh, but I prefer to write in /bin/sh.
Lyndon Nerenberg says:
This conversation is cool. It reminds me of a phone call I had with
somebody in the "pit" at AT&T tech support, arguing about why they could
never drop '^' as the "pipeline" separator in their SVR1 /bin/sh. The
lad was absolutely convinced '|' was an expression of the new heretics,
and would not stand past the next corporate quarter.
Man, I had to look that up ... SVR1 came out in 1983 :-) And I can
barely find any mention of ^ as the pipeline separator character.
Aleksander Matuszak says:
It does not seem too difficult to implement function which splits
any string into separate pieces and prepend them to exec*
parameters. But discussion shows that fundamental question is
rather: should it be passed to the shell (and gives chance to use
!$ or some such) or replace the shell job and interpret string inside
the code?
Well, the problem is that one of the examples you posted wouldn't work
with simple space splitting; we'd need to interpret quotes. Then we'd
need to specify how to escape quotes, then we'd want complete backslash
escape support .... it just gets awful quickly. If we can say, "it's
run under /bin/sh -c" then that lets people use the Bourne shell syntax
which is actually standardized.
Paul Fox says:
summary: i think passing any moreproc entry that contains whitespace
to "/bin/sh -c '%s'", and documenting it as such, would be fine.
processes aren't nearly as expensive as they used to be
I'll probably work on it in a few weeks ... I might just do the
space-splitting anyway since the code has mostly been written.
Ralph Corderoy says:
IOW, system(3).
Not exactly. In the case of moreproc it's actually a popen clone (m_popen).
In the case of Editor it's closer to system(), but some extra stuff happens
after the fork and before the exec(), so we can't just use system().
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers