[Issue 8 drafts 0001785]: Conflict in specification of processing of declaration utilities

2024-01-04 Thread Austin Group Bug Tracker via austin-group-l at The Open Group


The following issue has been RESOLVED. 
== 
https://austingroupbugs.net/view.php?id=1785 
== 
Reported By:kre
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1785
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: Resolved
Name:   Robert Elz 
Organization:
User Reference:  
Section:XCU 2.9.1.1 
Page Number:2483 
Line Number:80766-80778, 80790-80792 
Final Accepted Text:https://austingroupbugs.net/view.php?id=1785#c6614 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2023-10-28 04:09 UTC
Last Modified:  2024-01-04 16:56 UTC
== 
Summary:Conflict in specification of processing of
declaration utilities
==
Relationships   ID  Summary
--
related to  0001535 Poor description of declaration (all re...
related to  0001393 'command' should not be treated as a de...
related to  351 certain shell special built-ins should ...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-10-28 04:09 kreNew Issue
2023-10-28 04:09 kreName  => Robert Elz  
2023-10-28 04:09 kreSection   => XCU 2.9.1.1 
2023-10-28 04:09 krePage Number   => 2483
2023-10-28 04:09 kreLine Number   => 80766-80778,
80790-80792
2023-10-28 05:48 kreNote Added: 0006557  
2023-10-28 06:27 Don Cragun Relationship added   related to 0001535  
2023-10-28 06:28 Don Cragun Relationship added   related to 0001393  
2023-10-28 06:30 Don Cragun Relationship added   related to 351  
2023-10-30 14:07 chet_ramey Note Added: 0006559  
2023-12-11 15:37 geoffclare Note Added: 0006597  
2023-12-11 23:19 kreNote Added: 0006601  
2023-12-18 16:54 shware_systems Note Added: 0006612  
2024-01-04 16:54 geoffclare Note Added: 0006614  
2024-01-04 16:56 geoffclare Final Accepted Text   =>
https://austingroupbugs.net/view.php?id=1785#c6614
2024-01-04 16:56 geoffclare Status   New => Resolved 
2024-01-04 16:56 geoffclare Resolution   Open => Accepted As
Marked
==




[Issue 8 drafts 0001785]: Conflict in specification of processing of declaration utilities

2024-01-04 Thread Austin Group Bug Tracker via austin-group-l at The Open Group


A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1785 
== 
Reported By:kre
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1785
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Robert Elz 
Organization:
User Reference:  
Section:XCU 2.9.1.1 
Page Number:2483 
Line Number:80766-80778, 80790-80792 
Final Accepted Text: 
== 
Date Submitted: 2023-10-28 04:09 UTC
Last Modified:  2024-01-04 16:54 UTC
== 
Summary:Conflict in specification of processing of
declaration utilities
==
Relationships   ID  Summary
--
related to  0001535 Poor description of declaration (all re...
related to  0001393 'command' should not be treated as a de...
related to  351 certain shell special built-ins should ...
== 

-- 
 (0006614) geoffclare (manager) - 2024-01-04 16:54
 https://austingroupbugs.net/view.php?id=1785#c6614 
-- 
On page 2483 line 80766 section 2.9.1.1, change:The first word
(if any) that is not a variable assignment or redirection shall be
expanded. If any fields remain following its expansion, the first field
shall be considered the command name. If no fields remain, the next word
(if any) shall be expanded, and so on, until a command name is found or no
words remain. If there is a command name and it is recognized as a
declaration utility, then any remaining words after the word that expanded
to produce the command name, that would be recognized as a variable
assignment in isolation, shall be expanded as a variable assignment (tilde
expansion after the first  and after any unquoted ,
parameter expansion, command substitution, arithmetic expansion, and quote
removal, but no field splitting or pathname expansion); while remaining
words that would not be a variable assignment in isolation shall be subject
to regular expansion (tilde expansion for only a leading , parameter
expansion, command substitution, arithmetic expansion, field splitting,
pathname expansion, and quote removal). For all other command names, words
after the word that produced the command name shall be subject only to
regular expansion. All fields resulting from the expansion of the word that
produced the command name and the subsequent words, except for the field
containing the command name, shall be the arguments for the
command.to:The first word (if any) that is not a
variable assignment or redirection, and any subsequent words, shall be
processed as follows:
The first word may be matched lexically against the names of
declaration utilities.
The first word shall be expanded.
If any fields remain following expansion of the first word, the first
field shall be considered the command name. If no fields remain, the next
word (if any) shall be expanded, and so on, until a command name is found
or no words remain.
If the above optional matching against the names of declaration
utilities was not performed and there is a command name, the command name
shall be matched lexically against the names of declaration
utilities.
If whichever of the matching operations that was performed produced a
successful match, any remaining words after the word that expanded to
produce the command name, that would be recognized as a variable assignment
in isolation, shall be expanded as a variable assignment (tilde expansion
after the first  and after any unquoted , parameter
expansion, command substitution, arithmetic expansion, and quote removal,
but no field splitting or pathname expansion); while remaining words that
would not be a variable assignment in isolation shall be subject to regular
expansion (tilde expansion for only a leading , parameter expansion,
command substitution, arithmetic expansion, field splitting, pathname
expansion, and quote removal). If the matching operation did not produce a
successful match, words after the word that produced the command name shall
be subject only to regular expansion.
All fields resulting from the expansion of the word that pro

[Issue 8 drafts 0001785]: Conflict in specification of processing of declaration utilities

2023-12-11 Thread Austin Group Bug Tracker via austin-group-l at The Open Group


A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1785 
== 
Reported By:kre
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1785
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Robert Elz 
Organization:
User Reference:  
Section:XCU 2.9.1.1 
Page Number:2483 
Line Number:80766-80778, 80790-80792 
Final Accepted Text: 
== 
Date Submitted: 2023-10-28 04:09 UTC
Last Modified:  2023-12-11 15:37 UTC
== 
Summary:Conflict in specification of processing of
declaration utilities
==
Relationships   ID  Summary
--
related to  0001535 Poor description of declaration (all re...
related to  0001393 'command' should not be treated as a de...
related to  351 certain shell special built-ins should ...
== 

-- 
 (0006597) geoffclare (manager) - 2023-12-11 15:37
 https://austingroupbugs.net/view.php?id=1785#c6597 
-- 
Suggested changes...

On page 2483 line 80769 section 2.9.1.1, change:If there is a
command name and it is recognized as a declaration utility, then any
remaining words after the word that expanded to produce the command name,
...to:If there is a command name, the shell shall
use one of the following methods to check whether the utility to be invoked
is a declaration utility: The value, prior to expansion, of the
word that expanded to produce the command name is matched lexically against
the names of declaration utilities.
The command name is matched lexically against the names of declaration
utilities.If the chosen method identifies the utility to be
invoked as a declaration utility, then any remaining words after the word
that expanded to produce the command name, ...
On page 2483 line 80778 section 2.9.1.1, change:For all other
command names, words after the word that produced the command name shall be
subject only to regular expansion.to:If the
utility to be invoked is not identified as a declaration utility, words
after the word that produced the command name shall be subject only to
regular expansion.
On page 2483 line 80790 section 2.9.1.1, delete:When
determining whether a command name is a declaration utility, an
implementation may use only lexical analysis. It is unspecified whether
assignment context will be used if the command name would only become
recognized as a declaration utility after word expansions. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-10-28 04:09 kreNew Issue
2023-10-28 04:09 kreName  => Robert Elz  
2023-10-28 04:09 kreSection   => XCU 2.9.1.1 
2023-10-28 04:09 krePage Number   => 2483
2023-10-28 04:09 kreLine Number   => 80766-80778,
80790-80792
2023-10-28 05:48 kreNote Added: 0006557  
2023-10-28 06:27 Don Cragun Relationship added   related to 0001535  
2023-10-28 06:28 Don Cragun Relationship added   related to 0001393  
2023-10-28 06:30 Don Cragun Relationship added   related to 351  
2023-10-30 14:07 chet_ramey Note Added: 0006559  
2023-12-11 15:37 geoffclare Note Added: 0006597  
==




[Issue 8 drafts 0001785]: Conflict in specification of processing of declaration utilities

2023-10-30 Thread Austin Group Bug Tracker via austin-group-l at The Open Group


A NOTE has been added to this issue. 
== 
https://www.austingroupbugs.net/view.php?id=1785 
== 
Reported By:kre
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1785
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Robert Elz 
Organization:
User Reference:  
Section:XCU 2.9.1.1 
Page Number:2483 
Line Number:80766-80778, 80790-80792 
Final Accepted Text: 
== 
Date Submitted: 2023-10-28 04:09 UTC
Last Modified:  2023-10-30 14:07 UTC
== 
Summary:Conflict in specification of processing of
declaration utilities
==
Relationships   ID  Summary
--
related to  0001535 Poor description of declaration (all re...
related to  0001393 'command' should not be treated as a de...
related to  351 certain shell special built-ins should ...
== 

-- 
 (0006559) chet_ramey (reporter) - 2023-10-30 14:07
 https://www.austingroupbugs.net/view.php?id=1785#c6559 
-- 
Look at issue 1393 for a discussion about why it's acceptable to recognize
such names lexically: so the parser can allow extended assignment syntax
such as compound array assignment.

Since the NetBSD sh doesn't have those, you can ignore it. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-10-28 04:09 kreNew Issue
2023-10-28 04:09 kreName  => Robert Elz  
2023-10-28 04:09 kreSection   => XCU 2.9.1.1 
2023-10-28 04:09 krePage Number   => 2483
2023-10-28 04:09 kreLine Number   => 80766-80778,
80790-80792
2023-10-28 05:48 kreNote Added: 0006557  
2023-10-28 06:27 Don Cragun Relationship added   related to 0001535  
2023-10-28 06:28 Don Cragun Relationship added   related to 0001393  
2023-10-28 06:30 Don Cragun Relationship added   related to 351  
2023-10-30 14:07 chet_ramey Note Added: 0006559  
==




[Issue 8 drafts 0001785]: Conflict in specification of processing of declaration utilities

2023-10-27 Thread Austin Group Bug Tracker via austin-group-l at The Open Group


The following issue has been set as RELATED TO issue 351. 
== 
https://austingroupbugs.net/view.php?id=1785 
== 
Reported By:kre
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1785
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Robert Elz 
Organization:
User Reference:  
Section:XCU 2.9.1.1 
Page Number:2483 
Line Number:80766-80778, 80790-80792 
Final Accepted Text: 
== 
Date Submitted: 2023-10-28 04:09 UTC
Last Modified:  2023-10-28 06:30 UTC
== 
Summary:Conflict in specification of processing of
declaration utilities
==
Relationships   ID  Summary
--
related to  0001535 Poor description of declaration (all re...
related to  0001393 'command' should not be treated as a de...
related to  351 certain shell special built-ins should ...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-10-28 04:09 kreNew Issue
2023-10-28 04:09 kreName  => Robert Elz  
2023-10-28 04:09 kreSection   => XCU 2.9.1.1 
2023-10-28 04:09 krePage Number   => 2483
2023-10-28 04:09 kreLine Number   => 80766-80778,
80790-80792
2023-10-28 05:48 kreNote Added: 0006557  
2023-10-28 06:27 Don Cragun Relationship added   related to 0001535  
2023-10-28 06:28 Don Cragun Relationship added   related to 0001393  
2023-10-28 06:30 Don Cragun Relationship added   related to 351  
==




[Issue 8 drafts 0001785]: Conflict in specification of processing of declaration utilities

2023-10-27 Thread Austin Group Bug Tracker via austin-group-l at The Open Group


The following issue has been set as RELATED TO issue 0001393. 
== 
https://austingroupbugs.net/view.php?id=1785 
== 
Reported By:kre
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1785
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Robert Elz 
Organization:
User Reference:  
Section:XCU 2.9.1.1 
Page Number:2483 
Line Number:80766-80778, 80790-80792 
Final Accepted Text: 
== 
Date Submitted: 2023-10-28 04:09 UTC
Last Modified:  2023-10-28 06:28 UTC
== 
Summary:Conflict in specification of processing of
declaration utilities
==
Relationships   ID  Summary
--
related to  0001535 Poor description of declaration (all re...
related to  0001393 'command' should not be treated as a de...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-10-28 04:09 kreNew Issue
2023-10-28 04:09 kreName  => Robert Elz  
2023-10-28 04:09 kreSection   => XCU 2.9.1.1 
2023-10-28 04:09 krePage Number   => 2483
2023-10-28 04:09 kreLine Number   => 80766-80778,
80790-80792
2023-10-28 05:48 kreNote Added: 0006557  
2023-10-28 06:27 Don Cragun Relationship added   related to 0001535  
2023-10-28 06:28 Don Cragun Relationship added   related to 0001393  
==




[Issue 8 drafts 0001785]: Conflict in specification of processing of declaration utilities

2023-10-27 Thread Austin Group Bug Tracker via austin-group-l at The Open Group


The following issue has been set as RELATED TO issue 0001535. 
== 
https://austingroupbugs.net/view.php?id=1785 
== 
Reported By:kre
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1785
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Robert Elz 
Organization:
User Reference:  
Section:XCU 2.9.1.1 
Page Number:2483 
Line Number:80766-80778, 80790-80792 
Final Accepted Text: 
== 
Date Submitted: 2023-10-28 04:09 UTC
Last Modified:  2023-10-28 06:27 UTC
== 
Summary:Conflict in specification of processing of
declaration utilities
==
Relationships   ID  Summary
--
related to  0001535 Poor description of declaration (all re...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-10-28 04:09 kreNew Issue
2023-10-28 04:09 kreName  => Robert Elz  
2023-10-28 04:09 kreSection   => XCU 2.9.1.1 
2023-10-28 04:09 krePage Number   => 2483
2023-10-28 04:09 kreLine Number   => 80766-80778,
80790-80792
2023-10-28 05:48 kreNote Added: 0006557  
2023-10-28 06:27 Don Cragun Relationship added   related to 0001535  
==




[Issue 8 drafts 0001785]: Conflict in specification of processing of declaration utilities

2023-10-27 Thread Austin Group Bug Tracker via austin-group-l at The Open Group


A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1785 
== 
Reported By:kre
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1785
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Robert Elz 
Organization:
User Reference:  
Section:XCU 2.9.1.1 
Page Number:2483 
Line Number:80766-80778, 80790-80792 
Final Accepted Text: 
== 
Date Submitted: 2023-10-28 04:09 UTC
Last Modified:  2023-10-28 05:48 UTC
== 
Summary:Conflict in specification of processing of
declaration utilities
== 

-- 
 (0006557) kre (reporter) - 2023-10-28 05:48
 https://austingroupbugs.net/view.php?id=1785#c6557 
-- 
This issue is very much related to https://austingroupbugs.net/view.php?id=1535
(the resolution to which
was applied in Feb 2022, which is well before Issue 8 Draft 3, so the
text from that bug resolution is what was considered here).

In https://austingroupbugs.net/view.php?id=1535 I pointed out this contradictory
text, but that part of
the issue was completely ignored...   It still needs fixing. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-10-28 04:09 kreNew Issue
2023-10-28 04:09 kreName  => Robert Elz  
2023-10-28 04:09 kreSection   => XCU 2.9.1.1 
2023-10-28 04:09 krePage Number   => 2483
2023-10-28 04:09 kreLine Number   => 80766-80778,
80790-80792
2023-10-28 05:48 kreNote Added: 0006557  
==




[Issue 8 drafts 0001785]: Conflict in specification of processing of declaration utilities

2023-10-27 Thread Austin Group Bug Tracker via austin-group-l at The Open Group


The following issue has been SUBMITTED. 
== 
https://austingroupbugs.net/view.php?id=1785 
== 
Reported By:kre
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1785
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Robert Elz 
Organization:
User Reference:  
Section:XCU 2.9.1.1 
Page Number:2483 
Line Number:80766-80778, 80790-80792 
Final Accepted Text: 
== 
Date Submitted: 2023-10-28 04:09 UTC
Last Modified:  2023-10-28 04:09 UTC
== 
Summary:Conflict in specification of processing of
declaration utilities
Description: 
In XCU 2.9.1.1 bullet point 2, ut is said:

 The first word (if any) that is not a variable assignment or
redirection  
 shall be expanded.   If any fields remain following its expansion,
the
 first field shall be considered the command name. If no fields
remain,
 the next word (if any) shall be expanded, and so on, until a command
name
 is found or no words remain.

All that is fine and boring, then it continues:

 If there is a command name and it is recognized as a declaration
utility,
 then any remaining words after the word that expanded to produce the
 command name, that would be recognized as a variable assignment in
 isolation, shall be expanded as a variable assignment  [...]

(it goes on to what all of that means, which is not important here).

Note the required sequence, "the first word shall be expanded" ... [If
there is one and] "it is recognised as a declaration utility" ... "shall
be
expanded as a variable assignment" ...

There is nothing optional about what is specified there, first expand
the word(s), then having found the command name, check if it (the result
of the expansion) is a declaration utility, and if so do the special
processing
that is to be required of such things.

But later, after the bullet points, at lines 80790-80792 (right at the
bottom of page 2483) it says:

When determining whether a command name is a declaration utility, an
implementation may use only lexical analysis.

That isn't what the previous text seems to require to me.

It is unspecified whether assignment context will be used if the
command name would only become recognized as a declaration utility
after word expansions.

To me, that looks to be very explicitly specified, as quoted above.




Desired Action: 
Reconcile this nonsense.

Best would be to delete the notion of "declaration utilities" completely,
or at least make them optional (unspecified whether such things work).

They're never needed, one can always simply write

export FOO
FOO=whatever-I-like

and the assignment will be handled as a var-assign, without any magic
special rules (those two statements can be written in either order, except
for "readonly" where the assignment must come first), or if you prefer,
the following also works

FOO=whatever-I-like export FOO

if you really need to do it all in one statement.

This declaration utility nonsense (the special rules for arg processing)
were added just to pacify people who don't understand the order in which
the shell parses commands in general, and the syntax of the parts.  What's
more, including it, then leads to people wondering why (if we assume
a file named "foo bar" (without the quotes) exists in '.'

dd if=~/foo* ...
or
awk -v var=foo* ...

aren't parsed the same way, after all, they look just the same, your
average shell command line user has no idea what a "declaration utility"
might be.   Must easier to explain that the special rules for things which
look like (and always are) var-assigns apply only to those which appear
before the command name, as soon as there is anything (other than a
redirect)
all the special processing stops.

But in any case, this "shall do ..." followed immediately by "may be done
differently" needs to be fixed, one way or the other - either change
bullet
point 2 to make all of what it says about finding declaration utilities
optional, or simply remove lines 90790-2, and require it to be implemented
as in bullet point 2.

[Aside: none of this means much to me, I have no intention of implementing
"declaration utilities" whichever scheme were to be adopted.]


== 

Issue History 
Date ModifiedUsername