Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001009 [1003.1(2013)/Issue7+TC1] Shell and Utilities Objection Error 2015-11-20 00:59 2024-06-11 08:58
Reporter rhansen View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Richard Hansen
Organization BBN
User Reference
Section 2.9.1, 2.14 item #2, 2.14 set -a
Page Number 2339, 2356
Line Number 74354-74361, 75105-75106
Interp Status ---
Final Accepted Text Note: 0003379
Summary 0001009: "remain in affect after" and "during the execution" are problematic when built-in/function modifies the variable
Description The following script:
    x=set unset x
    printf %s\\n "${x-unset}"
outputs "unset" in existing implementations, but Section 2.14 item #2 (as modified by 0000654) says:
... variable assignments preceding the invocation of a special built-in utility remain in effect after the built-in completes; ....
This suggests that the above script should output "set" instead, which is clearly wrong.

Similarly, both
    printf %s\\n "x=bar" >tmp.sh
    x=foo . ./tmp.sh
    printf %s\\n "${x}"
and
    x=foo eval "x=bar"
    printf %s\\n "${x}"
output "bar" in existing implementations, not "foo".
Desired Action (Specific proposed wording to be provided later.)
  • 2.9.1: Make it clear that the effects of the assignments (including possible export attributes) happen before the execution of the command.
  • 2.9.1: Change the "during the execution" wording to something that makes it clear that the effects of the assignment aren't intended to override the behavior of the special built-in or function.
  • 2.14 item #2: Fix the "remain in effect" wording to agree with 2.9.1.
  • 2.14 item #2: Does "other utility" include functions? (Is a function a utility?) If so, fix the "this shall not be the case" wording to agree with 2.9.1.
  • 2.14 set -a: Move the specification describing the effects of -a on assignments preceding commands to 2.9.1 and make sure it's all consistent.
Tags tc3-2008
Attached Files

- Relationships
related to 0000654Closedajosey 1003.1(2013)/Issue7+TC1 unclear behavior of in-line variable assignments preceding functions, special built-ins 
related to 0001555Closed 1003.1(2016/18)/Issue7+TC2 -a/allexport spec should cover ${var=value} and ${var:=value} 

-  Notes
(0002970)
shware_systems (reporter)
2015-11-22 19:55
edited on: 2015-11-27 14:55

 Perhaps switching it to the opposite case, of when assignments do not affect the shell, is the clearer alternative in 2.9.1:
    "An assignment expression associated with a simple command that shall be executed in a sub-shell or separate process shall not preserve the effect of the assignment. It shall be applied after the context of local and exported variables is established for that sub-shell or process and not affect the current shell context otherwise. This shall include any function definition invocations with the same name identifier as a regular utility, standard or implementation-defined, and utilities implemented as regular built-in utilities."

This leaves implied that assignment expressions (specifically ASSIGNMENT_WORD tokens of the simple_command grammar production) before special utilities, as built-in invocations or separate executables, and functions are to behave as separate assignment statements in their effect on the current shell context, including auto-export and persistence of unset. The qualification for function definitions is for ensuring the behavior is similar whether the regular utility is implemented only as a separate executable or script, or has a built-in or a function definition version also.

The behavior if a function name happens to match another filename found during path search marked as executable would default to the shell doesn't care, invoke the function as if it wasn't found. Providing similar behavior for user-installed applications would be left as an extension, in other words, nominally out of scope as a configuration issue.
(0003353)
geoffclare (manager)
2016-08-18 15:42
edited on: 2016-08-18 16:15

 V7TC2D4 Page 2366, Line 75516, (TC2D3 #75172), Section: 2.9.1 Change:
If the command name is a special built-in utility, variable assignments shall affect the current execution environment.
to:
If the command name is a special built-in utility, variable assignments shall affect the current execution environment before the utility is executed and remain in effect when the command completes, along with any modifications to those assignments made by the utility.

Change V7TC2D4 XCU 2.14, Item 2 (Page 2385, L76309) from:
2. As described in Section 2.9.1, variable assignments preceding the invocation of a special built-in utility remain in effect after the built-in completes; this shall not be the case with a regular built-in or other utility.
to:
2. As described in Section 2.9.1, variable assignments preceding the invocation of a special built-in utility affect the current execution environment; this shall not be the case with a regular built-in or other utility.
(0003360)
rhansen (manager)
2016-08-25 15:15

 Don't we still need to fix the description of 'set -a' (page 2380 lines 75816-75817)?
(0003363)
geoffclare (manager)
2016-08-26 08:30
edited on: 2016-08-26 08:33

 Oops - seems we overlooked set -a in the teleconference.

Suggested replacement text (V7TC2D4 P2409 L77097):
Set the export attribute for all variable assignments that affect the current execution environment. When this option is on, the export attribute shall be set for each variable to which an assignment is performed (see [xref to XBD Section 4.23]) that affects the current execution environment (see [xref to 2.9.1]), or which is set as a result of the operation of the getopts or read utilities. This option shall have no effect on assignments that do not affect the current execution environment.
(0003368)
kre (reporter)
2016-08-29 04:28

 Since this is still being discussed, I'd suggest that the wording the
proposed resolution ...

   along with any modifications to those assignments made by the utility.

is not really as clear as it could be. That is, it suggests that (somehow)
the assignments should remain in effect, together with changes made by the
utility (both of them) - which is clearly not what is wanted.

Perhaps that clause could be replaced by something more like

   unless the variable in assignment is further modified by the utility,
   in which case the modifications made by the utility shall persist.

kre
(0003379)
geoffclare (manager)
2016-09-15 15:34

 V7TC2D4 Page 2366, Line 75516, (TC2D3 #75172), Section: 2.9.1 Change:
If the command name is a special built-in utility, variable assignments shall affect the current execution environment.
to:
If the command name is a special built-in utility, variable assignments shall affect the current execution environment before the utility is executed and remain in effect when the command completes; if an assigned variable is further modified by the utility, the modifications made by the utility shall persist.
Change V7TC2D4 XCU 2.14, Item 2 (Page 2385, L76309) from:
2. As described in Section 2.9.1, variable assignments preceding the invocation of a special built-in utility remain in effect after the built-in completes; this shall not be the case with a regular built-in or other utility.
to:
2. As described in Section 2.9.1, variable assignments preceding the invocation of a special built-in utility affect the current execution environment; this shall not be the case with a regular built-in or other utility.
Change the description of set -a (V7TC2D4 P2409 L77097-77103) from:
When this option is on, the export attribute shall be set for each variable to which an assignment is performed; see XBD Section 4.23. If the assignment precedes a utility name in a command, the export attribute shall not persist in the current execution environment after the utility completes, with the exception that preceding one of the special built-in utilities causes the export attribute to persist after the built-in has completed. If the assignment does not precede a utility name in the command, or if the assignment is a result of the operation of the getopts or read utilities, the export attribute shall persist until the variable is unset.
to:
Set the export attribute for all variable assignments. When this option is on, a variable that is assigned a value (see [xref to XBD Section 4.23]), including variables that are assigned a value by the getopts, read, or cd utilities, shall cause that variable to gain the export attribute. Note: As discussed in [xref to XCU 2.9.1], not all variable assignments happen in the current execution environment. When an assignment happens in a separate execution environment the export attribute is still set for the variable, but that does not affect the current execution environment.

- Issue History
Date Modified Username Field Change
2015-11-20 00:59 rhansen New Issue
2015-11-20 00:59 rhansen Name => Richard Hansen
2015-11-20 00:59 rhansen Organization => BBN
2015-11-20 00:59 rhansen Section => 2.9.1, 2.14 item #2, 2.14 set -a
2015-11-20 00:59 rhansen Page Number => 2339, 2356
2015-11-20 00:59 rhansen Line Number => 74354-74361, 75105-75106
2015-11-20 00:59 rhansen Interp Status => ---
2015-11-20 01:01 rhansen Relationship added related to 0000654
2015-11-20 01:04 rhansen Tag Attached: tc3-2008
2015-11-22 19:55 shware_systems Note Added: 0002970
2015-11-27 14:55 shware_systems Note Edited: 0002970
2016-08-18 15:42 geoffclare Note Added: 0003353
2016-08-18 15:43 geoffclare Final Accepted Text => Note: 0003353
2016-08-18 15:43 geoffclare Status New => Resolved
2016-08-18 15:43 geoffclare Resolution Open => Accepted As Marked
2016-08-18 15:44 geoffclare Note Edited: 0003353
2016-08-18 16:06 geoffclare Note Edited: 0003353
2016-08-18 16:15 geoffclare Note Edited: 0003353
2016-08-25 15:15 rhansen Note Added: 0003360
2016-08-26 08:30 geoffclare Note Added: 0003363
2016-08-26 08:30 geoffclare Status Resolved => Under Review
2016-08-26 08:30 geoffclare Resolution Accepted As Marked => Reopened
2016-08-26 08:32 geoffclare Note Edited: 0003363
2016-08-26 08:33 geoffclare Note Edited: 0003363
2016-08-29 04:28 kre Note Added: 0003368
2016-09-15 15:34 geoffclare Note Added: 0003379
2016-09-15 15:35 geoffclare Final Accepted Text Note: 0003353 => Note: 0003379
2016-09-15 15:35 geoffclare Resolution Reopened => Accepted As Marked
2016-09-15 15:37 geoffclare Status Under Review => Resolved
2019-10-23 14:35 geoffclare Status Resolved => Applied
2022-03-31 15:52 nick Relationship added related to 0001555
2024-06-11 08:58 agadmin Status Applied => Closed

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