[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 22 Oct 2021 09:53:00 +0100
From: Stephane Chazelas <stephane@...zelas.org>
To: Rob Landley <rob@...dley.net>
Cc: enh <enh@...gle.com>, Rich Felker <dalias@...c.org>,
austin-group-l <austin-group-l@...ngroup.org>,
libc-coord@...ts.openwall.com
Subject: Re: Posix issue 8 pending change to system().
2021-10-22 01:11:43 -0500, Rob Landley via austin-group-l at The Open Group:
[...]
> > > Where system("-blah") fails because sh is insane legacy weirdness and it turns
> > > out that -c does NOT take an argument. So:
> > >
> > > sh -c -i "echo hello"
> > >
> > > Works, which that means "sh -c -potato" tries to parse -potato as an option, and
> > > fails.
[...]
Note that if it was even insaner legacy, it would be fine.
In the Bourne shell, only the first argument was considered for
options.
In the Bourne shell originally, you'd have had to write:
sh -fc 'echo hello'
Or
sh -cf 'echo hello'
to interpret "echo hello" while the f option is enabled. sh -c
-f 'echo hello' would interpret -f with "echo hello" in $0.
So system() was broken when sh started accepting more than one
option argument.
Similarly, the
#! /bin/sh -euf
scripts were broken in the same way for the same reason (modern
versions of sh still accept #! /bin/sh - as a way to mark the
end of options, but that can't be used in combination with
options in most shebang implementations) -- off topic here as
POSIX doesn't specify shebangs.
See also
https://unix.stackexchange.com/questions/351729/why-the-in-the-bin-sh-shebang
Note that it applies to sh -c +potato as well.
[...]
> > > it's unclear whether anyone's actually hit this in practice? and even if they
> > had, their portable workaround would be to prefix with "exec "?
[...]
An easier workaround is:
system(" -potato") or system("\n-potato").
It's the same workaround you need to use with eval:
eval " $code"
as IIRC, eval being a special builtin, is not required to accept
"--" as option delimiter (even though most implementations do;
dash and bosh being some exceptions).
Note that in some shells (and it's now required by POSIX), "exec
cmd" runs cmd from $PATH bypassing function and builtins (and
aliases for those shells that have builtin aliases and where
"exec" is not an alias for "exec ").
So prepending "exec" can affect functionality, though in most
cases using "exec" can be a good idea especially with shells
that don't optimise out the fork by themselves for the last
command.
--
Stephane
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
