0001779: Standard does not say how much read should do if a read-only variable is given

Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Category

Severity

Type

Date Submitted

Last Update

0001779

[Issue 8 drafts] Shell and Utilities

Objection

Omission

2023-10-16 22:07

2023-12-07 14:22

Reporter

kre

View Status

public

Assigned To

Priority

normal

Resolution

Accepted As Marked

Status

Applied

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

0001778

Applied

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

Mantis 1.1.6[^]