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

2021-04-11 Thread Robert Elz via austin-group-l at The Open Group
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]

2021-04-11 Thread Robert Elz via austin-group-l at The Open Group
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]

2021-04-11 Thread Harald van Dijk via austin-group-l at The Open Group
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]

2021-04-11 Thread Joerg Schilling via austin-group-l at The Open Group
"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]

2021-04-11 Thread Joerg Schilling via austin-group-l at The Open Group
"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]

2021-04-11 Thread Harald van Dijk via austin-group-l at The Open Group
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]

2021-04-11 Thread Robert Elz via austin-group-l at The Open Group
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]

2021-04-11 Thread shwaresyst via austin-group-l at The Open Group
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]

2021-04-11 Thread Harald van Dijk via austin-group-l at The Open Group
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]

2021-04-11 Thread Joerg Schilling via austin-group-l at The Open Group
"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]

2021-04-11 Thread Robert Elz via austin-group-l at The Open Group
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-11 Thread Stephane Chazelas via austin-group-l at The Open Group
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]

2021-04-11 Thread Harald van Dijk via austin-group-l at The Open Group
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]

2021-04-11 Thread shwaresyst via austin-group-l at The Open Group
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]

2021-04-11 Thread Harald van Dijk via austin-group-l at The Open Group
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]

2021-04-11 Thread Robert Elz via austin-group-l at The Open Group
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]

2021-04-11 Thread Robert Elz via austin-group-l at The Open Group
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]

2021-04-11 Thread Harald van Dijk via austin-group-l at The Open Group
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]

2021-04-11 Thread Joerg Schilling via austin-group-l at The Open Group
"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]

2021-04-11 Thread Oğuz via austin-group-l at The Open Group
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]

2021-04-11 Thread shwaresyst via austin-group-l at The Open Group
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]

2021-04-11 Thread Harald van Dijk via austin-group-l at The Open Group
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

[Online Pubs 0001465]: trap synopsis missing newline

2021-04-11 Thread Austin Group Bug Tracker via austin-group-l at The Open Group
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1465 == Reported By:mihai_moldovan Assigned To:

[Online Pubs 0001465]: trap synopsis missing newline

2021-04-11 Thread Austin Group Bug Tracker via austin-group-l at The Open Group
The following issue has been SUBMITTED. == https://www.austingroupbugs.net/view.php?id=1465 == Reported By:mihai_moldovan Assigned To: