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
0001779 [Issue 8 drafts] Shell and Utilities Objection Omission 2023-10-16 22:07 2024-06-11 09:12
Reporter kre View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed   Product Version Draft 3
Name Robert Elz
Organization
User Reference
Section XCU 3/read
Page Number 3291
Line Number 111880-111882
Final Accepted Text See Note: 0006593.
Summary 0001779: Standard does not say how much read should do if a read-only variable is given
Description This issue is an offshoot from 0001788 as requested in Note: 0006534

As Note: 0006534 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.

Note: 0006534 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...")

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 read simply ceases processing when
the error occurs, leaving later named variables unaltered

Tags applied_after_i8d3, issue8
Attached Files

- Relationships
child of 0001778Closed The read utility needs field splitting updates/corrections )and a little more) 

-  Notes
(0006593)
Don Cragun (manager)
2023-11-30 16:28

After bug 0001778 has been applied...
Before P3291 L111882:
If it is called in a subshell...

add a new sentence:
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 read simply ceases processing when
the error occurs, leaving later named variables unaltered.

- 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
2023-11-30 16:17 nick Relationship added child of 0001788
2023-11-30 16:18 nick Relationship added parent of 0001778
2023-11-30 16:19 nick Relationship deleted child of 0001788
2023-11-30 16:20 nick Relationship replaced child of 0001778
2023-11-30 16:28 Don Cragun Note Added: 0006593
2023-11-30 16:29 Don Cragun Final Accepted Text => See Note: 0006593.
2023-11-30 16:29 Don Cragun Status New => Resolved
2023-11-30 16:29 Don Cragun Resolution Open => Accepted As Marked
2023-11-30 16:31 Don Cragun Tag Attached: issue8
2023-12-07 14:22 geoffclare Status Resolved => Applied
2023-12-07 14:22 geoffclare Tag Attached: applied_after_i8d3
2024-06-11 09:12 agadmin Status Applied => Closed


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