Date: Fri, 29 Oct 2021 13:47:59 +0000 (UTC)
From: shwaresyst <shwares...@aol.com>
Message-ID: <2020487850.3000042.1635515279...@mail.yahoo.com>
[Apologies: I sent this reply, just to Mark, a few minutes ago,
once again trapped by the evil "Reply-to" added by this list...
So, I am resending just to the list now - Mark, sorry you will end
up receiving this twice in a manner where you cannot easily just
suppress this copy as a duplicate. Rest assured that the remainder
of this message is identical to the previous one, including any
typos that might exist (with my messages, there are usually always
some), you need not read it again.]
| This is felt required to get POSIX accurately describing what the
| C standard version of system() requires,
I don't have a copy of that, so I have no idea what is in it.
| POSIX is as it is because it was assumed no programmer would use
| a option switch character as a utility name first character as
| recommended and so was superfluous,
I would at least hope that POSIX is as it is because
execl("/bin/sh", "sh", "-c", cmd, NULL);
(along with the fork and wait and ... of course) is what the
implementations do, and did ever since system() was invented.
That no-one felt the need to worry about the issue of *cmd being a '-'
(or '+') might be explained that way, which might also (along with shells
not actually supporting the "--" notation until relatively recently)
that in 40+ years of system()'s existence, essentially no real code
ever broke or failed to work because of it.
| So, the standard is more precise with it than without it.
The problem is that it isn't (even now) what most implementations do,
and that is what the standard should reflect.
Some standards bodies feel that they have a mandate (from who knows where)
to legislate on what is good and what isn't. We should resist that
temptation - no-one elected any of us to decide on goodness of the world
(or even of unix-like systems).
| Because the use of "--" is in an "shall behave as if" clause it is
| expository, not a coding requirement.
That entirely misses my point. The issue is that application writers
today *cannot* assume that the command can start with any arbitrary
character, and it will work, portably, everywhere. It just doesn't
work, and writing down in POSIX that it is required to work, is just
lying about the state of the universe. We should not be doing that.
That is, systems today do not "behave as if" (with the "--" included)
they "behave as if" with the form that is in the existing standard.
That's what application writers can expect, and if one writes
sh -c -f
one gets the same as
sh -f -c
which has the 'f' option set, and no command for -c to execute given
(and so, a usage error message from the shell of some kind).
In exactly the same way, if one writes, in a C program
system("-f");
the same thing happens, on almost all of today's systems. Perhaps
it might be better if it did not, but it has been that way forever.
| Some libraries use posix_spawn() to implement system(), for example.
I cannot even imagine why it makes a difference if one uses fork()/exec()
or posix_spawn() - the question is what command string whichever of those is
used actually executes. The function used in the implementation is
not even close to the issue here.
| Some may only add "--" if a check of the string determines it
| is necessary, as also allowed by the standard.
You're right, it is allowed. So is adding the "--" unilaterally,
which is much simpler, and just as effective -- surely no-one is going
to bother worrying about one more arg to execl (or one more entry in
the vector passed to execv()) or the extra pointer and 3 bytes of
string (--\0) that the kernel has to copy in, when the result is
going to be to start a sh running, with all of the overhead that
introduces.
There's no question but that implementations should add the "--", there's
no reason not to.
But that implementations *should* add that doesn't mean that POSIX
should tell people that implementations already do that, unless there
is good evidence that most of them do.
That's why I suggested that instead of the proposed resolution, text be
added strongly suggesting that implementations should do this, without
actually requiring it, and advising implementations to insert a white
space char at the head of the command string if there is any possibility
that it otherwise might start with a '-' or '+', as that is how to make
the applications actually work, today.
And the standard could pressure the implementations even more by indicating
that a later revision might require the "--", so they would be even more
likely to do the right thing.
But we should never lie, nor are we a legislature, we cannot command.
kre
