Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001629 [Online Pubs] Shell and Utilities Editorial Clarification Requested 2023-01-15 17:30 2023-01-20 21:18
Reporter mirabilos View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name mirabilos
Organization mksh
User Reference
URL unsure which applies
Section unsure which applies
Summary 0001629: Shell vs. read(2) errors on the script
Description As indicated in <Pine.BSM.4.64L.2301081426320.6999@herc.mirbsd.org> on the mailing list, both GNU bash <https://savannah.gnu.org/support/index.php?110763> [^] and mksh <https://bugs.launchpad.net/mksh/+bug/2002044> [^] 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.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0006120)
chet_ramey (reporter)
2023-01-20 21:18

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 Modified Username Field Change
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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker