The following issue has been SUBMITTED. ====================================================================== https://www.austingroupbugs.net/view.php?id=1779 ====================================================================== Reported By: kre Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1779 Category: Shell and Utilities Type: Omission Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section: XCU 3/read Page Number: 3291 Line Number: 111880-111882 Final Accepted Text: ====================================================================== Date Submitted: 2023-10-16 22:07 UTC Last Modified: 2023-10-16 22:07 UTC ====================================================================== Summary: Standard does not say how much read should do if a read-only variable is given Description: This issue is an offshoot from https://www.austingroupbugs.net/view.php?id=1788 as requested in https://www.austingroupbugs.net/view.php?id=1778#c6534
As https://www.austingroupbugs.net/view.php?id=1778#c6534 says, the standard currently says (lines 11180-2 of I.8 D.3) An error in setting any variable (such as if a var has previously been marked readonly) shall be considered an error of read processing, and shall result in a return value greater than one. https://www.austingroupbugs.net/view.php?id=1778#c6534 goes on to say: It is silent about when read exits (immediately or after processing later operands) so both behaviours are allowed. It is worse than that, there are 5 behaviours I can imagine which would be allowed by silence (unspecified because no-one thought to specify it) . The vars are checked to see if any is read only before read does any processing, and read does exit(2) before it even attempts to read anything if a read only var is detected. No vars altered. . the same check is done but after the input has been read, but before field splitting, no vars altered. . as each var is assigned a value, if it is read only (or the assignment fails for any other reason, such as ENOMEM to a malloc() request) then all processing stops, that var, and any following it are unchanged, previous vars have been assigned values already, and read does exit(2). . as each var is assigned a value, if it is read only (or the assignment fails for any other reason) the variable in question is left unaltered, but processing continues and other vars (if possible) are assigned values as if the one that failed had also been assigned a value. When complete, read does exit(2) . as each var is assigned a value, if it is read only (or the assignment fails for any other reason) the variable in question is left unaltered, all remaining vars are set to the null string (if assignments to them are possible) and read does exit(2) As best I can tell only the 3rd and 4th of those actually exist in shells. I have a general hatred of "implicitly unspecified" as this currently is, as that can lead to more varying implementation techniques (there may be more possible than I considered above ... perhaps simply setting all vars which can be set to the empty string if an assignment to any of them fails, kind of a combination of number 1, or 2, with number 5) when ideally we'd like to converge upon one behaviour that scripts could rely upon. Desired Action: Append after the sentence quoted in the description from lines 111880... of I.8 D.3 the following new sentence (Before "If it is called in a subshell...") <blockquote>Variables named before the one generating the error shall be set as described above, it is unspecified whether variables named later shall be set as above, or whether <i>read</i> simply ceases processing when the error occurs, leaving later named variables unaltered</blockquote> ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2023-10-16 22:07 kre New Issue 2023-10-16 22:07 kre Name => Robert Elz 2023-10-16 22:07 kre Section => XCU 3/read 2023-10-16 22:07 kre Page Number => 3291 2023-10-16 22:07 kre Line Number => 111880-111882 ======================================================================
