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
0001555 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Clarification Requested 2022-01-17 22:32 2024-06-11 09:07
Reporter McDutchie View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Martijn Dekker
Organization ksh 93u+m <https://github.com/ksh93/ksh> [^]
User Reference
Section XCU 2.14
Page Number 2381
Line Number 77125-77127
Interp Status Approved
Final Accepted Text Note: 0005769
Summary 0001555: -a/allexport spec should cover ${var=value} and ${var:=value}
Description It is currently not mentioned what effect, if any, the -a/allexport shell option should have on expansions of the form ${var=value} and ${var:=value}, nor is this explicitly unspecified.

Both the current draft phrase "Set the export attribute for all variable assignments", and the current release phrase "When this option is on, the export attribute shall be set for each variable to which an assignment is performed", seem to suggest that these expansions should cause the variable's export attribute to be set if they perform an assignment.

However, the subsequent reference to XBD Section 4.23, clarifying what is meant by a variable assignment, seems to contradict that, as (both in the release and the draft) that section only covers assignments of the form "var=value".

According to my testing, today's situation is that all current shells except ksh93, pdksh, mksh, and yash do set the export attribute for assignments performed via ${var=value} and ${var:=value} if the -a/allexport option is on.

In my view, the ksh93/pdksh/mksh/yash behaviour is a bug, and I would like to fix ksh93 and report the bug to the other shells' maintainers. But I think the standard's intention needs to be clarified.
Desired Action Possible resolutions that I can see (apologies for not coming up with an exact wording, I do not feel competent in that department):

* Amend the -a/allexport description to refer to both XBD 4.23 and default value assignments via parameter expansions per XCU 2.6.2.

* Amend the definition of assignments in XBD 4.23 to include default value assignments via parameter expansions per XCU 2.6.2.

* After line 77127, add a sentence clarifying that it is unspecified whether this option causes variables that are assigned a default value via a parameter expansion to be exported. (Not the option I would prefer.)
Tags tc3-2008
Attached Files

- Relationships
related to 0001009Closed 1003.1(2013)/Issue7+TC1 "remain in affect after" and "during the execution" are problematic when built-in/function modifies the variable 

-  Notes
(0005628)
McDutchie (reporter)
2022-01-19 02:35

Relevant response from Robert Elz: https://www.mail-archive.com/austin-group-l@opengroup.org/msg09035.html [^]

Particularly notable: assignment via arithmetic expansion has the same problem on the same shells. ksh93, pdksh/mksh, and yash do not export 'var' after 'unset var; set -a; : $((var=1))'.

I would edit the "Description" and "Desired Action" fields accordingly if I could, but this system doesn't seem to allow it.
(0005769)
geoffclare (manager)
2022-03-31 15:56

Interpretation response
------------------------
The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.

Rationale:
-------------
The reference to XBD 4.23 implies that only certain types of assignment are affected by -a, but the later text referring to getopts and read contradicts that.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------

On page 2409 line 77096 section 2.14 set, replace the description of the -a option with:
Set the export attribute for all variable assignments. When this option is on, whenever a value is assigned to a variable in the current shell execution environment, the export attribute shall be set for the variable. This applies to all forms of assignment, including those made as a side-effect of variable expansions or arithmetic expansions, and those made as a result of the operation of the cd, getopts, or read utilities.

<small>Note: As discussed in Section 2.9.1, not all variable assignments happen in the current execution environment. When an assignment happens in a separate shell execution environment, the export attribute is still set for the variable, but that does not affect the current shell execution environment.</small>

Note to the editor: the -a description differs between the 2018 edition and Issue 8 draft 2.1. This new description replaces both.
(0005812)
agadmin (administrator)
2022-04-21 15:07

Interpretation proposed: 21 April 2022
(0005843)
agadmin (administrator)
2022-05-23 11:27

Interpretation approved: 23 May 2022

- Issue History
Date Modified Username Field Change
2022-01-17 22:32 McDutchie New Issue
2022-01-17 22:32 McDutchie Name => Martijn Dekker
2022-01-17 22:32 McDutchie Organization => ksh 93u+m <https://github.com/ksh93/ksh> [^]
2022-01-17 22:32 McDutchie Section => XCU 2.14
2022-01-17 22:32 McDutchie Page Number => 2381
2022-01-17 22:32 McDutchie Line Number => 77125-77127
2022-01-19 02:35 McDutchie Note Added: 0005628
2022-03-31 15:52 nick Relationship added related to 0001009
2022-03-31 15:56 geoffclare Interp Status => Pending
2022-03-31 15:56 geoffclare Note Added: 0005769
2022-03-31 15:56 geoffclare Status New => Interpretation Required
2022-03-31 15:56 geoffclare Resolution Open => Accepted As Marked
2022-03-31 15:57 geoffclare Final Accepted Text => Note: 0005769
2022-03-31 15:57 geoffclare Tag Attached: tc3-2008
2022-04-21 15:07 agadmin Interp Status Pending => Proposed
2022-04-21 15:07 agadmin Note Added: 0005812
2022-05-23 11:27 agadmin Interp Status Proposed => Approved
2022-05-23 11:27 agadmin Note Added: 0005843
2022-06-17 08:34 geoffclare Status Interpretation Required => Applied
2024-06-11 09:07 agadmin Status Applied => Closed


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