View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001779Issue 8 draftsShell and Utilitiespublic2023-10-16 22:072024-06-11 09:12
Reporterkre Assigned To 
PrioritynormalSeverityObjectionTypeOmission
Status ClosedResolutionAccepted As Marked 
Product VersionDraft 3 
NameRobert Elz
Organization
User Reference
SectionXCU 3/read
Page Number3291
Line Number111880-111882
Final Accepted TextSee 0001779:0006593.
Summary0001779: Standard does not say how much read should do if a read-only variable is given
DescriptionThis issue is an offshoot from 0001788 as requested in 0001778:0006534

As 0001778: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.

0001778: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 ActionAppend 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

Tagsapplied_after_i8d3, issue8

Relationships

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

Activities

Don Cragun

2023-11-30 16:28

manager   bugnote:0006593

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 0001779: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