Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Date:Tue, 13 Apr 2021 10:16:26 +0100 From:Harald van Dijk Message-ID: <7ab68758-b423-ae1b-4451-cd02c4b6b...@gigawatt.nl> I think we have probably largely converged about this issue (with Chet's assistance) so this will probably be my last message about it. |

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 13/04/2021 14:43, Chet Ramey wrote: On 4/13/21 5:16 AM, Harald van Dijk via austin-group-l at The Open Group wrote: Please note again that POSIX's Command Search and Execution doesn't say "continue until execve() doesn't fail". It says "Otherwise, the command shall be searched for using

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 4/13/21 5:16 AM, Harald van Dijk via austin-group-l at The Open Group wrote: Please note again that POSIX's Command Search and Execution doesn't say "continue until execve() doesn't fail". It says "Otherwise, the command shall be searched for using the PATH environment variable as described

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 12/04/2021 21:57, Robert Elz wrote: Date:Mon, 12 Apr 2021 18:42:03 +0100 From:Harald van Dijk Message-ID: | No, not anything. It still has to be shell start-up activity. And your definition of what is a shell start-up activity comes from ? When

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Date:Mon, 12 Apr 2021 18:42:03 +0100 From:Harald van Dijk Message-ID: | No, not anything. It still has to be shell start-up activity. And your definition of what is a shell start-up activity comes from ? | The starting a thread would be shell start-up

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 12/04/2021 20:22, (Joerg Schilling) wrote: Harald van Dijk wrote: On 12/04/2021 12:47, (Joerg Schilling) wrote: Do you have a private variant og ksh93v? I get the same behavior from ksh88, the ksh93 from OpenSolaris and ksh93v. I don't. I was testing with ksh built from

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

12 Nisan 2021 Pazartesi tarihinde David A. Wheeler via austin-group-l at The Open Group yazdı: > > > On Apr 12, 2021, at 1:51 PM, Oğuz wrote: > > Taking "always double-quote your dollar variables", "eval is evil, avoid > it", etc. as "the rule" is cargo cult programming. Average programmer's >

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Harald van Dijk wrote: > On 12/04/2021 12:47, (Joerg Schilling) wrote: > > Do you have a private variant og ksh93v? > > > > I get the same behavior from ksh88, the ksh93 from OpenSolaris and ksh93v. > > I don't. I was testing with ksh built from >

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

> On Apr 12, 2021, at 1:51 PM, Oğuz wrote: > Taking "always double-quote your dollar variables", "eval is evil, avoid it", > etc. as "the rule" is cargo cult programming. Average programmer's > incompetence doesn't make the shell broken or unsafe or anything like that > and doesn't justify

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 4/12/21 12:05 PM, Robert Elz via austin-group-l at The Open Group wrote: Anything that the system can run, no matter how it does that, is acceptable. If a system noticed a VAX format a.out, it could load a vax simulator, and run the binary that way, without the user even noticing. If it

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

12 Nisan 2021 Pazartesi tarihinde David A. Wheeler yazdı: > > > On Apr 12, 2021, at 10:57 AM, Oğuz wrote: > 12 Nisan 2021 Pazartesi tarihinde David A. Wheeler via austin-group-l at > The Open Group yazdı: >> >> If you want a robust shell script, I recommend that you try out the tool >>

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 12/04/2021 12:47, (Joerg Schilling) wrote: Harald van Dijk wrote: If they are mistakes, they are widespread mistakes. As hinted in the links, with PATH=/bin:/usr/bin, /bin/gcc and /usr/bin/gcc both existing as files with execute permission, but /bin/gcc as a text file containing #!/bad so

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 12/04/2021 00:25, Robert Elz wrote: Date:Sun, 11 Apr 2021 22:27:19 +0100 From:Harald van Dijk Message-ID: <79b98e30-46ba-d468-153f-c1a2a0416...@gigawatt.nl> | Okay, but that is a technicality. The pre-seeding is only permitted at | startup time, No,

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

> On Apr 12, 2021, at 10:57 AM, Oğuz wrote: > 12 Nisan 2021 Pazartesi tarihinde David A. Wheeler via austin-group-l at The > Open Group > yazdı: > If you want a robust shell script, I recommend that you try out the tool > “shellcheck”. > That checks a

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

"Robert Elz via austin-group-l at The Open Group" wrote: > Date:Mon, 12 Apr 2021 15:07:28 + (UTC) > From:shwaresyst > Message-ID: <1662152200.1116623.1618240048...@mail.yahoo.com> > > | Then that is conformance bugs in those kernels, > > Rubbish. > > |

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Date:Sun, 11 Apr 2021 14:02:15 +0200 From:"Joerg Schilling via austin-group-l at The Open Group" Message-ID: <20210411120215.wchk4%sch...@schily.net> | If command -v should become able to do more, we would need to invent a | way to execute _any_ utility

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Date:Mon, 12 Apr 2021 15:07:28 + (UTC) From:shwaresyst Message-ID: <1662152200.1116623.1618240048...@mail.yahoo.com> | Then that is conformance bugs in those kernels, Rubbish. | in that files of this type are not load images exec() is to handle There is no

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Then that is conformance bugs in those kernels, to me, in that files of this type are not load images exec() is to handle that are usable with dl*(). The allowance is for magics differentiating formats of that nature, as I see as the intent, not one bypassing what the shell is supposed to

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

12 Nisan 2021 Pazartesi tarihinde David A. Wheeler via austin-group-l at The Open Group yazdı: > > If you want a robust shell script, I recommend that you try out the tool > “shellcheck”. > That checks a shell script against a set of recommended practices (e.g., > use “$variable” not $variable).

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

> On Apr 10, 2021, at 5:54 AM, Jan Hafer via austin-group-l at The Open Group > wrote: > ... > 2. In an ideal scenario the semantic of a word can be make constant, so no > other script or shell invocation running afterwards can change it (this would > compare to best practices in compiled

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Harald van Dijk wrote: > That is an implementation detail. As far as POSIX is concerned, there is > only a single command search when a command is executed, so "a > subsequent invocation" can only refer to the shell script attempting to > execute the same command again at a later time. POSIX

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Robert Elz wrote: > Actually, in my, and I suspect most, implementations, even the first > will invoke the "subsequent" clause, as the (parent) shell first searches > PATH to find the executable, and enters it in the hash table. Then it > forks, and the child repeats the whole thing (after

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 4/11/21 4:17 PM, shwaresyst via austin-group-l at The Open Group wrote: conforming applications can not rely on unspecified behaviors, so having a use beyond that specified makes the shell nonconforming. Calling it out like that simply acknowledges a lot of shell implementations choose to

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

"shwaresyst via austin-group-l at The Open Group" wrote: > No, it's not nonsense. The definition of comment has all characters, > including '!', shall be ignored until newline or end-of-file being > conforming. Then tokenization which might discover an operator, keyword or > command

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Harald van Dijk wrote: > >> If they are mistakes, they are widespread mistakes. As hinted in the > >> links, with PATH=/bin:/usr/bin, /bin/gcc and /usr/bin/gcc both existing > >> as files with execute permission, but /bin/gcc as a text file containing > >> #!/bad so that any attempt to execute

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Date:Sun, 11 Apr 2021 22:27:19 +0100 From:Harald van Dijk Message-ID: <79b98e30-46ba-d468-153f-c1a2a0416...@gigawatt.nl> | Okay, but that is a technicality. The pre-seeding is only permitted at | startup time, No, what it says is "an unspecified shell

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Date:Sun, 11 Apr 2021 20:17:09 + (UTC) From:shwaresyst 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

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 11/04/2021 22:05, Robert Elz wrote: Date:Sun, 11 Apr 2021 19:46:36 +0100 From:Harald van Dijk Message-ID: <9ab286f9-125d-55a4-a65f-08d4af04d...@gigawatt.nl> | Sure, that's why I then switched to a different example that did not | have an earlier

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

"shwaresyst via austin-group-l at The Open Group" wrote: > 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. For > those shells implementing shebang as an extension it is still them piping the

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

"shwaresyst via austin-group-l at The Open Group" wrote: > No, it's not nonsense. The definition of comment has all characters, > including '!', shall be ignored until newline or end-of-file being > conforming. Then tokenization which might discover an operator, keyword or > command

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 11/04/2021 21:17, shwaresyst wrote: The requirement explicitly specified behavior shall be implemented as specified takes priority. Some conforming script authors may simply want the first line to be a # IMPORTANT USAGE NOTE headline, or

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Date:Sun, 11 Apr 2021 19:46:36 +0100 From:Harald van Dijk Message-ID: <9ab286f9-125d-55a4-a65f-08d4af04d...@gigawatt.nl> | Sure, that's why I then switched to a different example that did not | have an earlier "command -v" to point out how this leads to

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

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. For those shells implementing shebang as an extension it is still them piping the body of the script after the shebang line, without any token

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 11/04/2021 17:50, Robert Elz wrote: Date:Sun, 11 Apr 2021 17:04:05 +0100 From:Harald van Dijk Message-ID: <92113e70-5605-10f4-8e57-47c9f64cd...@gigawatt.nl> | This only applies when a remembered location exists at all, though. Yes, but in the examples I

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

"Stephane Chazelas via austin-group-l at The Open Group" wrote: > 2021-04-10 22:12:47 +0200, Joerg Schilling via austin-group-l at The Open > Group: > > "Jan Hafer via austin-group-l at The Open Group" > > wrote: > > > > > For a short recap why: There are `which, type, command, whence,

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Date:Sun, 11 Apr 2021 17:04:05 +0100 From:Harald van Dijk Message-ID: <92113e70-5605-10f4-8e57-47c9f64cd...@gigawatt.nl> | This only applies when a remembered location exists at all, though. Yes, but in the examples I showed, it did (you can see that from the

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

2021-04-10 22:12:47 +0200, Joerg Schilling via austin-group-l at The Open Group: > "Jan Hafer via austin-group-l at The Open Group" > wrote: > > > For a short recap why: There are `which, type, command, whence, where, > > whereis, whatis, hash` used in shells. Worse, the semantics of `which`

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 11/04/2021 17:09, shwaresyst via austin-group-l at The Open Group wrote: No, it's not nonsense. The definition of comment has all characters, including '!', shall be ignored until newline or end-of-file being conforming. Then tokenization which might discover an operator, keyword or command

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

No, it's not nonsense. The definition of comment has all characters, including '!', shall be ignored until newline or end-of-file being conforming. Then tokenization which might discover an operator, keyword or command continues. This precludes "#!" being recognized as any of those. There is NO

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 11/04/2021 16:33, Robert Elz wrote: Date:Sun, 11 Apr 2021 13:25:46 +0100 From:Harald van Dijk Message-ID: | > My tests show that ksh, bash, yash, mksh do not find gcc in that case. | | Huh. My tests with ksh were with 93v, it's possible different

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Date:Sun, 11 Apr 2021 10:46:48 + (UTC) From:shwaresyst Message-ID: <1413127944.766378.1618138008...@mail.yahoo.com> | That's bugs in those shells for POSIX mode then, that I see. That's nonsense. | The conforming behavior is /usr/gcc is found and succeeds

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Date:Sun, 11 Apr 2021 13:25:46 +0100 From:Harald van Dijk Message-ID: | > My tests show that ksh, bash, yash, mksh do not find gcc in that case. | | Huh. My tests with ksh were with 93v, it's possible different versions | behave differently. I see the

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 11/04/2021 13:02, Joerg Schilling via austin-group-l at The Open Group wrote: "Harald van Dijk via austin-group-l at The Open Group" wrote: If they are mistakes, they are widespread mistakes. As hinted in the links, with PATH=/bin:/usr/bin, /bin/gcc and /usr/bin/gcc both existing as files

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

"Harald van Dijk via austin-group-l at The Open Group" wrote: > If they are mistakes, they are widespread mistakes. As hinted in the > links, with PATH=/bin:/usr/bin, /bin/gcc and /usr/bin/gcc both existing > as files with execute permission, but /bin/gcc as a text file containing > #!/bad

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On Sun, Apr 11, 2021 at 1:47 PM shwaresyst via austin-group-l at The Open Group wrote: > That's bugs in those shells for POSIX mode then, that I see. The > conforming behavior is /usr/gcc is found and succeeds at doing nothing, > since it contains just a comment line. Other elements of path

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

That's bugs in those shells for POSIX mode then, that I see. The conforming behavior is /usr/gcc is found and succeeds at doing nothing, since it contains just a comment line. Other elements of path never get checked. Even in non-POSIX mode, trying to process it as a shebang with "/bad" as a

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On 10/04/2021 17:08, Robert Elz via austin-group-l at The Open Group wrote: Date:Sat, 10 Apr 2021 11:54:34 +0200 From:"Jan Hafer via austin-group-l at The Open Group" Message-ID: <15c15a5b-2808-3c14-7218-885e704cc...@rwth-aachen.de> | my inquiry is a

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

On Sat, 2021-04-10 at 22:12 +0200, Joerg Schilling via austin-group-l at The Open Group wrote: > where ??? what is that? I don't know if this is what Jan was thinking of, but "where" exists on Windows and is equivalent to "which" etc. there.

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

"Jan Hafer via austin-group-l at The Open Group" wrote: > For a short recap why: There are `which, type, command, whence, where, > whereis, whatis, hash` used in shells. Worse, the semantics of `which` > is shell-dependent. which is a csh script and unrelated to Bourne or POSIX

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Date:Sat, 10 Apr 2021 23:08:40 +0700 From:"Robert Elz via austin-group-l at The Open Group" Message-ID: <20226.1618070...@jinx.noi.kre.to> Now to add to something I said in the previous reply (so so the rest of the audience here don't think I have suddenly changed

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Date:Sat, 10 Apr 2021 11:54:34 +0200 From:"Jan Hafer via austin-group-l at The Open Group" Message-ID: <15c15a5b-2808-3c14-7218-885e704cc...@rwth-aachen.de> | my inquiry is a question about the potential unexpected behavior of the | shell execution environment

[Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Dear Ladies and Gentlemen, my inquiry is a question about the potential unexpected behavior of the shell execution environment on names. It is related to shortcomings of the command utility. Related page for command utlity semantics: