Just for reference, the C standard says:
> If string is not a null pointer, the *system* function passes the string
pointed to
> by *string* to that command processor to be executed in a manner which
the implementation shall
> document; this might then cause the program calling system to behave in a
non-conforming manner
> or to terminate.
So Mark's comment:
| This is felt required to get POSIX accurately describing what the
| C standard version of system() requires,
is inaccurate, since C makes almost no promises at all!
And you are absolutely correct, current POSIX implementations do not do
this, even though they should!
So I agree, we should change the wording here so that for Issue 7 we only
state what implementations should expect to do when Issue 8 comes out, and
give application developers strong warnings about how to work around the
issues caused by the possible (certain?) loss of the '--' in existing
implementations.
On Fri, Oct 29, 2021 at 9:33 AM Robert Elz via austin-group-l at The Open
Group <austin-group-l@opengroup.org> wrote:
> 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
>
>
>
>
