On 2/7/23 2:22 AM, Andrew Josey via austin-group-l at The Open Group wrote:
Bug 1629: Shell vs. read(2) errors on the script OPEN
https://austingroupbugs.net/view.php?id=1629
This item was discussed at length on the call
including the feedback from Chet Ramey. Notes were updated in
the etherpad -- https://posix.rhansen.org/p/2023-02-06 .
I looked at the etherpad. Nick, thanks for the detail about the script.
There are some missing details about what happens on read errors. One
thing is that bash assumes fatal read(2) errors are *not* transient: when
a read returns -1/EWHATEVER, if errno is not EINTR or EAGAIN the next read
will also return an error. Same with EOF. This is, of course, not how it
goes when you inject read errors. With that in mind:
> /tmp/shell.script: line 1227: ent: command not found
> $ echo $?
> 42
>
> (i.e. it treated the end of "# this is a comment" as the command "ent"
> and continued execution)
is reasonably easy to explain. Bash, like all the shells, converts the read
error into EOF and executes the partial line, which happens to be a
comment. Then it goes back to read, assuming that a real error will result
in another -1/EIO (as it will in virtually all situations). Since the read
succeeds, the error must have been transient, and it goes on. Other shells
do things differently.
The key is that everyone `executes' the partial line after getting EOF,
even yash.
Nick's example shows this, if you convert it to a non-interactive shell
instance.
printf "echo foo" | bash
will output `foo' in bash and every other shell. Same with interactive
shells.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
