 Relationships |
|
| Anonymous | Login | 2023-01-29 08:33 UTC |
| Main | My View | View Issues | Change Log | Docs |
| 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 |  |
