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
0000255 [1003.1(2008)/Issue 7] Shell and Utilities Objection Clarification Requested 2010-05-19 09:04 2013-04-16 13:06
Reporter geoffclare View Status public  
Assigned To ajosey
Priority normal Resolution Accepted  
Status Closed  
Name Geoff Clare
Organization The Open Group
User Reference
Section 2.9.1
Page Number 2317
Line Number 73101-73106
Interp Status Approved
Final Accepted Text Note: 0000426
Summary 0000255: shell expansions in assignments that precede a command name
Description Current shell implementations differ in how they process expansions
within assignments that precede a command name. For example

unset X; X=a Y=$X sh -c 'echo +$X+ +$Y+'

produces "+a+ +a+" in some shells and "+a+ ++" in others. If an
expansion includes an assignment as a side-effect, such as

unset X; X= Y=${X:=b} sh -c 'echo +$X+ +$Y+'; echo /$X/

then three different behaviours are observed in different shells.

The standard is at best unclear on this issue. (At worst, a
strict reading is possible which requires behaviour that does not
match the majority of existing practice.) Following a discussion
on the mailing list, changes are proposed which would explicitly
allow all the different existing behaviours for non-readonly
variables but retaining a strict requirement when an assignment
to a readonly variable is attempted.

The proposed changes also correct a minor issue that came to
light during the discussion: since functions have the same
variable-assignment properties as special built-ins (see 2.9.5),
it makes sense for 2.9.1 to mention both instead of just special
built-ins.
Desired Action Change

    If no command name results, variable assignments shall affect the
    current execution environment. Otherwise, the variable assignments
    shall be exported for the execution environment of the command and
    shall not affect the current execution environment (except for
    special built-ins). If any of the variable assignments attempt to
    assign a value to a read-only variable, a variable assignment
    error shall occur. See [xref to 2.8.1 Consequences of Shell Errors]
    for the consequences of these errors.

to

    If no command name results, or if the command name is a special
    built-in or function, variable assignments shall affect the
    current execution environment. Otherwise, the variable assignments
    shall be exported for the execution environment of the command and
    shall not affect the current execution environment except as a
    side-effect of the expansions performed in step 4. In this case
    it is unspecified
 
     . whether or not the assignments are visible for subsequent
       expansions in step 4;
 
     . whether variable assignments made as side-effects of these
       expansions are visible for subsequent expansions in step 4, or
       in the current shell execution environment, or both.

    If any of the variable assignments attempt to assign a value to
    a variable for which the readonly attribute is set in the
    current shell environment (regardless of whether the assignment
    is made in that environment), a variable assignment error shall
    occur. See [xref to 2.8.1 Consequences of Shell Errors] for the
    consequences of these errors.
Tags tc1-2008
Attached Files

- Relationships
has duplicate 0000562Closedajosey Optional Arguments Setting Current Execution Environment Is Not Noted for functions (only for built-ins) 

-  Notes
(0000426)
ajosey (manager)
2010-06-03 15:33

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:
-------------
None.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
See the Desired Action
(0000506)
ajosey (manager)
2010-07-30 09:27

Comments/objections on the proposed interpretation are due by 31 Aug 2010
(0000535)
eblake (manager)
2010-08-30 17:54
edited on: 2010-08-30 17:56

I'm wondering if we are still missing text regarding side-effects of expansions performed during step 2. That is, do I have a guarantee that:

unset a; test "${a=b}"; echo ${a+set}

will always echo "set", or does the proposed wording still permit an implementation to fork upon recognizing that test is a simple command that is not a special built in, prior to expanding "${a=b}", such that the subsequent echo still sees $a as unset?

(0000537)
ajosey (manager)
2010-09-02 15:31

(from DGK, mail seq austin-group-l:archive/latest/14431)

I don't think that this was ever an issue. Command arguments are always
expanded in the current environment whether the command is built-in or
not. In fact you might not know the command until the arguments
are expanded. Thus, a will be set.

The only area of contention that I am aware of is

    unset a; "${a=b}" test ; echo ${a-set}

since some shells expand could expand parameter assignment lists in
a subshell environment. The Bourne shell, for example, forked()
after expanding command arguments when the command was not a built-in.

- Issue History
Date Modified Username Field Change
2010-05-19 09:04 geoffclare New Issue
2010-05-19 09:04 geoffclare Status New => Under Review
2010-05-19 09:04 geoffclare Assigned To => ajosey
2010-05-19 09:04 geoffclare Name => Geoff Clare
2010-05-19 09:04 geoffclare Organization => The Open Group
2010-05-19 09:04 geoffclare Section => 2.9.1
2010-05-19 09:04 geoffclare Page Number => 2317
2010-05-19 09:04 geoffclare Line Number => 73101-73106
2010-05-19 09:04 geoffclare Interp Status => ---
2010-06-03 15:33 ajosey Interp Status --- => Proposed
2010-06-03 15:33 ajosey Note Added: 0000426
2010-06-03 15:33 ajosey Status Under Review => Interpretation Required
2010-06-03 15:33 ajosey Resolution Open => Accepted
2010-06-03 15:34 ajosey Interp Status Proposed => Pending
2010-06-03 15:34 ajosey Final Accepted Text => Note: 0000426
2010-07-30 09:27 ajosey Interp Status Pending => Proposed
2010-07-30 09:27 ajosey Note Added: 0000506
2010-08-30 17:54 eblake Note Added: 0000535
2010-08-30 17:56 eblake Note Edited: 0000535
2010-09-02 15:31 ajosey Note Added: 0000537
2010-09-24 16:17 geoffclare Tag Attached: tc1-2008
2010-11-11 17:29 ajosey Interp Status Proposed => Approved
2012-05-04 08:10 geoffclare Relationship added has duplicate 0000562
2013-04-16 13:06 ajosey Status Interpretation Required => Closed


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