[Online Pubs 0001629]: Shell vs. read(2) errors on the script

[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=1629 
== 
Reported By:mirabilos
Assigned To:
== 
Project:Online Pubs
Issue ID:   1629
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   mirabilos 
Organization:   mksh 
User Reference:  
URL:unsure which applies 
Section:unsure which applies 
== 
Date Submitted: 2023-01-15 17:30 UTC
Last Modified:  2023-02-09 16:59 UTC
== 
Summary:Shell vs. read(2) errors on the script
==
Relationships   ID  Summary
--
related to  367 interaction between readonly, export, g...
== 

-- 
 (0006145) geoffclare (manager) - 2023-02-09 16:59
 https://austingroupbugs.net/view.php?id=1629#c6145 
-- 
The following is a proposed resolution for this bug, but it is not existing
practice in almost all shells (they treat a read error like end-of-file)
and so we would like feedback from shell authors to indicate whether they
are willing to make changes to follow these new requirements. The rationale
for requesting this change in behavior is that executing the partial line
after getting a read error is really not a good thing for any shell to do. 
Consider a shell script that contains the command:rm -f --
*.tmpIf the shell successfully reads "rm -f -- *" and
then gets an error when it tries to read ".tmp", it will execute "rm -f --
*", resulting in data loss.

Please send feedback by March 9, 2023.

Add a row (D2.1 p2330)  to the table in 2.8.1 Consequences of Shell Errors:
   
Read error when reading commands | shall exit *4 | shall exit
*4 | yes
and add a new note after the table:
4.  If a partial command was read before the read error
occurred, that partial command shall not be executed.
Add to the exit status section of the sh utility on P3155 after L107008:
1-126A read error was detected while reading
commands. 

Change P3155, L107009-107011 in the exit status section of the sh utility
from:
1-125A non-interactive shell detected an error
other than command_file not found or executable, including but not
limited to syntax, redirection, or variable assignment
errors.
to:
1-125A non-interactive shell detected an error
other than command_file not found, command_file not
executable, or a read error while reading commands; including but not
limited to syntax, redirection, or variable assignment
errors. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-01-15 17:30 mirabilos  New Issue
2023-01-15 17:30 mirabilos  Name  => mirabilos   
2023-01-15 17:30 mirabilos  Organization  => mksh
2023-01-15 17:30 mirabilos  URL   => unsure which
applies
2023-01-15 17:30 mirabilos  Section   => unsure which
applies
2023-01-20 21:18 chet_ramey Note Added: 0006120  
2023-01-30 16:45 nick   Relationship added   related to 367  
2023-02-02 15:51 chet_ramey Note Added: 0006142  
2023-02-04 17:46 chet_ramey Note Added: 0006143  
2023-02-09 16:59 geoffclare Note Added: 0006145  
==

[Online Pubs 0001629]: Shell vs. read(2) errors on the script

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://www.austingroupbugs.net/view.php?id=1629 
== 
Reported By:mirabilos
Assigned To:
== 
Project:Online Pubs
Issue ID:   1629
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   mirabilos 
Organization:   mksh 
User Reference:  
URL:unsure which applies 
Section:unsure which applies 
== 
Date Submitted: 2023-01-15 17:30 UTC
Last Modified:  2023-02-04 17:46 UTC
== 
Summary:Shell vs. read(2) errors on the script
==
Relationships   ID  Summary
--
related to  367 interaction between readonly, export, g...
== 

-- 
 (0006143) chet_ramey (reporter) - 2023-02-04 17:46
 https://www.austingroupbugs.net/view.php?id=1629#c6143 
-- 
I sent this to austin-group-l:

I looked at the etherpad. I'm not sure who tested bash-5.2.2 (Nick?), but
you ended up running something that a vendor -- probably Ubuntu via Debian
--
modified to add an error message.

I can't tell what `/tmp/script' is, but running bash-5.2.15 on RHEL7

$ ./bash --version
GNU bash, version 5.2.15(5)-release (x86_64-pc-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later


This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

against the following script:

$ cat x10
echo a; echo b;
echo after: $?

exits with status 0 after a read error:

$ strace -e trace=read -e inject=read:error=ESTALE:when=7 ./bash ./x10
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\316\0\0\0\0\0\0"..., 832)
= 832
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\16\0\0\0\0\0\0"..., 832) =
832
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`&\2\0\0\0\0\0"...,
832) = 832
read(3, "MemTotal:1862792 kB\nMemF"..., 1024) = 1024
read(3, "echo a; echo b;\necho after: $?\n", 80) = 31
read(255, "echo a; echo b;\necho after: $?\n", 31) = 31
a
b
after: 0
read(255, 0x26d0290, 31)= -1 ESTALE (Stale file handle)
(INJECTED)
+++ exited with 0 +++

You have to make sure you inject the error when bash is reading input
for the parser (the fifth read is checking whether or not the script is a
binary file). You'd get the same results with when=6.

You didn't check dash, but it returns 0 as well. I assume the other ash-
derived BSD shells behave similarly. yash is still the only shell that
returns an error in this case. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-01-15 17:30 mirabilos  New Issue
2023-01-15 17:30 mirabilos  Name  => mirabilos   
2023-01-15 17:30 mirabilos  Organization  => mksh
2023-01-15 17:30 mirabilos  URL   => unsure which
applies
2023-01-15 17:30 mirabilos  Section   => unsure which
applies
2023-01-20 21:18 chet_ramey Note Added: 0006120  
2023-01-30 16:45 nick   Relationship added   related to 367  
2023-02-02 15:51 chet_ramey Note Added: 0006142  
2023-02-04 17:46 chet_ramey Note Added: 0006143  
==

[Online Pubs 0001629]: Shell vs. read(2) errors on the script

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been set as RELATED TO issue 367. 
== 
https://austingroupbugs.net/view.php?id=1629 
== 
Reported By:mirabilos
Assigned To:
== 
Project:Online Pubs
Issue ID:   1629
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   mirabilos 
Organization:   mksh 
User Reference:  
URL:unsure which applies 
Section:unsure which applies 
== 
Date Submitted: 2023-01-15 17:30 UTC
Last Modified:  2023-01-30 16:45 UTC
== 
Summary:Shell vs. read(2) errors on the script
==
Relationships   ID  Summary
--
related to  367 interaction between readonly, export, g...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-01-15 17:30 mirabilos  New Issue
2023-01-15 17:30 mirabilos  Name  => mirabilos   
2023-01-15 17:30 mirabilos  Organization  => mksh
2023-01-15 17:30 mirabilos  URL   => unsure which
applies
2023-01-15 17:30 mirabilos  Section   => unsure which
applies
2023-01-20 21:18 chet_ramey Note Added: 0006120  
2023-01-30 16:45 nick   Relationship added   related to 367  
==

[Online Pubs 0001629]: Shell vs. read(2) errors on the script

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://www.austingroupbugs.net/view.php?id=1629 
== 
Reported By:mirabilos
Assigned To:
== 
Project:Online Pubs
Issue ID:   1629
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   mirabilos 
Organization:   mksh 
User Reference:  
URL:unsure which applies 
Section:unsure which applies 
== 
Date Submitted: 2023-01-15 17:30 UTC
Last Modified:  2023-02-02 15:51 UTC
== 
Summary:Shell vs. read(2) errors on the script
==
Relationships   ID  Summary
--
related to  367 interaction between readonly, export, g...
== 

-- 
 (0006142) chet_ramey (reporter) - 2023-02-02 15:51
 https://www.austingroupbugs.net/view.php?id=1629#c6142 
-- 
I see that the minutes of the 30 January meeting begin to address this. The
summary says that this is "partially handled by ...
https://www.austingroupbugs.net/view.php?id=367";. I assume
that means for errors during the `read' builtin.

It's far from clear that an EIO (or ESTALE, or whatever) error while
reading a script is meant to be one of the "an error other than ...," but
if it is, it's best to state that explicitly instead of hiding behind the
"including, but not limited to" language. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-01-15 17:30 mirabilos  New Issue
2023-01-15 17:30 mirabilos  Name  => mirabilos   
2023-01-15 17:30 mirabilos  Organization  => mksh
2023-01-15 17:30 mirabilos  URL   => unsure which
applies
2023-01-15 17:30 mirabilos  Section   => unsure which
applies
2023-01-20 21:18 chet_ramey Note Added: 0006120  
2023-01-30 16:45 nick   Relationship added   related to 367  
2023-02-02 15:51 chet_ramey Note Added: 0006142  
==

[Online Pubs 0001629]: Shell vs. read(2) errors on the script

[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=1629 
== 
Reported By:mirabilos
Assigned To:
== 
Project:Online Pubs
Issue ID:   1629
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   mirabilos 
Organization:   mksh 
User Reference:  
URL:unsure which applies 
Section:unsure which applies 
== 
Date Submitted: 2023-01-15 17:30 UTC
Last Modified:  2023-01-20 21:18 UTC
== 
Summary:Shell vs. read(2) errors on the script
== 

-- 
 (0006120) chet_ramey (reporter) - 2023-01-20 21:18
 https://austingroupbugs.net/view.php?id=1629#c6120 
-- 
As part of the discussion on savannah, I looked into different shells'
behavior.

The only shell that reflects a read error into $? is yash. The rest,
including bash, treat read errors the same as EOF and exit with the last
command's exit status. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-01-15 17:30 mirabilos  New Issue
2023-01-15 17:30 mirabilos  Name  => mirabilos   
2023-01-15 17:30 mirabilos  Organization  => mksh
2023-01-15 17:30 mirabilos  URL   => unsure which
applies
2023-01-15 17:30 mirabilos  Section   => unsure which
applies
2023-01-20 21:18 chet_ramey Note Added: 0006120  
==

[Online Pubs 0001629]: Shell vs. read(2) errors on the script

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://austingroupbugs.net/view.php?id=1629 
== 
Reported By:mirabilos
Assigned To:
== 
Project:Online Pubs
Issue ID:   1629
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   mirabilos 
Organization:   mksh 
User Reference:  
URL:unsure which applies 
Section:unsure which applies 
== 
Date Submitted: 2023-01-15 17:30 UTC
Last Modified:  2023-01-15 17:30 UTC
== 
Summary:Shell vs. read(2) errors on the script
Description: 
As indicated in  on the
mailing list, both GNU bash
 and mksh
 got reports that the shell
does not error out on read errors when loading either the first or any
subsequent block of the script to execute.

Chet says that treating them as EOF is historical behaviour.

I don’t have a preference either way as I can see benefit in both; in
contrast to Chet however I do think that the exit status mandated (if any)
does matter and would prefer a high one, or even suggesting that the shell
sends itself a suitable signal (PIPE, BUS and HUP, in that order, came to
mind) so that the script could even have installed a trap handler to catch
this condition beforehand (and clean up).

Desired Action: 
Decide whether…

① either ⓐ keep to existing behaviour; read errors on the script are
treated as EOF, and the shell is still required to exit with the errorlevel
of the last command executed (if any; a read error on the first block of a
script would equal executing a null command and therefore exit zero),
  or ⓑ that read errors on script input require exiting indicating an
error in some way,

and ② if 1b, how shells are supposed to treat these errors; options are
at least
  ⓒ some code within 1‥125, as with other errors,
  ⓓ 126 as if the script was not executable (which will require changing
126 as it’s IIRC currently tied to ENOEXEC),
  ⓔ signalling itself with a suitable signal,
  ⓕ exiting with 128+signalnumber of the signal,
  ⓖ any other, possibly high, status.

I dislike 2c (which the bug submitter suggests as he interprets the spec
this way currently) for possible confusion with utility exit statūs (grep,
diff, cURL, unifdef, etc).
I’m not sure about 2d but it sounds good.
As mentioned above, I’d prefer 2e iff 1b is decided on (I’m similarly
good with 1a, I just want a well-argumented decision either way).
If 2e is not palatable, I’d rank 2f almost as high as 2d.
2g has the potential of conflicting with 2f for possibly unrelated
signals.

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-01-15 17:30 mirabilos  New Issue
2023-01-15 17:30 mirabilos  Name  => mirabilos   
2023-01-15 17:30 mirabilos  Organization  => mksh
2023-01-15 17:30 mirabilos  URL   => unsure which
applies
2023-01-15 17:30 mirabilos  Section   => unsure which
applies
==