A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1465
==
Reported By:mihai_moldovan
Assigned To:
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 question
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 ENO
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 never
"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 so
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
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 same
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 at
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 ve
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
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
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`
>
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
outp
"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, where
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 s
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 expan
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 inconsist
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 simila
"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 continues
"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
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 "command
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
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 start-
23 matches
Mail list logo