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