Date: Sun, 11 Apr 2021 20:17:09 +0000 (UTC) From: shwaresyst <shwares...@aol.com> Message-ID: <1360977422.847706.1618172229...@mail.yahoo.com>
| We are talking about the shell, not some bastardization of execve(), | that sees it's not a directly loadable process image so treats it as | a script. shells only do that when the error is ENOEXEC. In the cases we were discussing, it was not. Had there been an ENOEXEC error, then the shells would (all I believe) have attempted to run the file as a script. But that wasn't the error, so they (rightly) did not. The use of #!/bad (and similar) is simply an easy way (on most kernels, ie: those which support #!) to get the exec to fail with an error other than ENOEXEC. It is not the only way, name or path too long are also possibilities, so is a smylink loop, ... there are many possibilities. For those shells implementing shebang as an extension There are a couple that do that, but that's completely irrelevant, that only happens when the kernel doesn't support #! (all that matter do), and the shell is trying to do what any modern kernel would (should) do. Posix might not mandate #! support but the marketplace does. So: it is still them piping the body of the script after the shebang line, without any token expansion, to an alternate interpreter via an exec() of some sort. This is completely immaterial as no-one here is in any way considering this kind of case, we're not getting ENOEXEC errors. Second, conforming applications can not rely on unspecified behaviors, Of course. so having a use beyond that specified makes the shell nonconforming. Nonsense. Shells are allowed to implement extensions. They don't become non-conforming because of that. The reference shell (ksh88) implements extensions after all. Some conforming script authors may simply want the first line to be a #!!!! IMPORTANT USAGE NOTE !!!! headline, That's a contradiction. A conforming script cannot start that way. You have already been told why. It can start \n#!!! if it wants. It can even start \b#!!! if it wants to pretend (at least to people who look via "cat file") as if it starts #!!!. It cannot start #!anything. | What the standard does allow as an extension, | and I would support adding to the standard, is adding an option | to turn off token expansion in here-doc bodies, What does this have to do with the current discussion? | This allows the effect of shebang to be accomplished anywhere in a script, Nonsense. #! is not really for when shells run commands (though it helps), it is for when other utilities run commands find /where/ever -name something -exec my_cmd {} \; where "my_cmd" is awk, or perl, or python, or tcl, or ... I wasn't here when any austin-group discussions on #! were being held, but it is hard these days to think of any good reason for it not to be included, with the possible exception that executable formats in general are not specified. If that was it, I would think an exception for this one case would make sense. However #! has ***nothing*** to do with the current issue, it's just a tool to use for demonstrating what happens. The same issues can arise in lots of other ways. Please stop confusing things. If you don't understand what we're talking about, please just observe and try to learn something (feel free to ask questions). kre