Austin Group Defect Tracker

Aardvark Mark III

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000643 [1003.1(2008)/Issue 7] Shell and Utilities Objection Error 2013-01-16 04:08 2014-02-19 16:22
Reporter rhansen View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Interpretation Required  
Name Richard Hansen
User Reference
Section 2.10.2
Page Number 2326
Line Number 73470-73481
Interp Status Approved
Final Accepted Text See Note: 0001448
Summary 0000643: Reduction of TOKEN to WORD or ASSIGNMENT_WORD broken when TOKEN contains an equals sign
Description Each of the following:
    $(foo=bar; baz)
is one token according to XCU 2.3. According to XCU 2.10.2, the tokens match cmd_name, so rule 7a is applied. Each token contains an equals sign, so rule 7a says to apply rule 7b. The tokens do not begin with '=', nor do all characters preceding '=' form a valid name, so according to 7b it is unspecified whether ASSIGNMENT_WORD or WORD is returned. I believe WORD should be returned in these cases.

In addition:
  - The second bullet of rule 7b is unclear when TOKEN contains multiple <equals-sign> characters.
  - The phrase "all the characters preceding '='" could refer to characters in previous tokens. I believe the intention is to only refer to the preceding characters in the current token.
Desired Action Change the second bullet in rule 7b from:

    - If all the characters preceding '=' form a valid name (see XBD Section 3.231), the token ASSIGNMENT_WORD shall be returned. (Quoted characters cannot participate in forming a valid name.)


    - If all the token's characters preceding the first '=' form a valid name (see XBD Section 3.231), the token ASSIGNMENT_WORD shall be returned. (Quoted characters cannot participate in forming a valid name.)

And insert a new bullet after the second bullet in rule 7b:

    - If there are no unquoted <equals-sign> characters (excluding unquoted <equals-sign> characters in applicable tilde expansions, parameter expansions, command substitutions, and arithmetic expansions), WORD is returned.

(The suggested bullet could use some wordsmithing, but I believe the intention is clear.)
Tags tc2-2008
Attached Files

- Relationships
has duplicate 0000578Closedajosey 1003.1(2008)/Issue 7 "NAME" should be unbolded and lowercased 
related to 0000839Interpretation Required 1003.1(2013)/Issue7+TC1 problems with reduction of WORD to ASSIGNMENT_WORD 

-  Notes
nick (manager)
2013-01-17 17:27
edited on: 2013-01-17 17:28

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.

The current wording is ambiguous. However, there are currently conforming implementations with extensions (e.g. array assignments) that should not be outlawed by adding additional restrictions here.

Notes to the Editor (not part of this interpretation):
At page 2326, line 73477 change
 If all the characters preceding ’=’ ...

 If all the characters in the TOKEN preceding the first '=' ...

On page 2326 line 73482 change:
 Assignment to the NAME shall occur ...
 Assignment to the name within a returned ASSIGNMENT_WORD token shall occur ...

ajosey (manager)
2013-03-29 08:04

Interpretation Proposed 29 Mar 2013
ajosey (manager)
2013-05-03 12:20

Interpretation approved 3 May 2013
ajosey (manager)
2014-02-19 15:30

The second change in the Notes to the Editor (bugnote 01448) appears to already be covered by the change in Bug 578. The proposal here has slightly different wording to bug 578

Bug 578:

Change Number: XCU/TC2/D1/nn [578]

On Page: 2326 Line: 73482 Section: 2.10.2

In section 2.10.2 Shell Grammar Rules, change from:

Assignment to the NAME shall occur as specified in Section 2.9.1.


Assignment to the name before the '=' in the ASSIGNMENT_WORD shall occur as specified in Section 2.9.1
geoffclare (manager)
2014-02-19 16:22

Since this bug is an approved interpretation and 0000578 is not, we should probably use the wording from this bug in TC2 and retrospectively make 578 a duplicate of it.

- Issue History
Date Modified Username Field Change
2013-01-16 04:08 rhansen New Issue
2013-01-16 04:08 rhansen Status New => Under Review
2013-01-16 04:08 rhansen Assigned To => ajosey
2013-01-16 04:08 rhansen Name => Richard Hansen
2013-01-16 04:08 rhansen Section => 2.10.2
2013-01-16 04:08 rhansen Page Number => 2349
2013-01-16 04:08 rhansen Line Number => 74750--74761
2013-01-17 16:52 msbrown Project 2008-TC1 => 1003.1(2008)/Issue 7
2013-01-17 16:54 msbrown Page Number 2349 => 2326
2013-01-17 16:54 msbrown Line Number 74750--74761 => 73470-73481
2013-01-17 16:54 msbrown Interp Status => ---
2013-01-17 17:27 nick Note Added: 0001448
2013-01-17 17:28 nick Interp Status --- => Pending
2013-01-17 17:28 nick Final Accepted Text => See Note: 0001448
2013-01-17 17:28 nick Status Under Review => Interpretation Required
2013-01-17 17:28 nick Resolution Open => Accepted As Marked
2013-01-17 17:28 nick Tag Attached: tc2-2008
2013-01-17 17:28 nick Note Edited: 0001448
2013-03-29 08:04 ajosey Interp Status Pending => Proposed
2013-03-29 08:04 ajosey Note Added: 0001516
2013-05-03 12:20 ajosey Interp Status Proposed => Approved
2013-05-03 12:20 ajosey Note Added: 0001580
2014-02-19 15:30 ajosey Note Added: 0002141
2014-02-19 16:22 geoffclare Note Added: 0002143
2014-02-20 16:21 geoffclare Relationship added has duplicate 0000578
2014-05-22 15:25 nick Relationship added related to 0000839

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