Re: Should shell quoting within glob bracket patterns be effective?

[Robert Elz]

I have also just realised that a better example than ${ in "" would have been
$( inside "".

There, because of the double quotes, the '(' is treated literally, as a '('
character, and not as the '(' operator.   But still when the command
substitition (inside the "") is performed, the '(' is available to be part
of the syttax, and is no longer treated literally at all.

Put that reasoning into the argument in the previous message, instead
of the ${ version and I think it becomes clearer how the current text
allows the '-' inside "a-c" to be treated literally, as the string is parsed
(not that that one would be treated differently anyway, any more than
the '{' would be in the ${ form) but still have its special meaning in
character ranges, just as the '(' (or '{' retains its special meaning in the
expansions.

kre

Re: Should shell quoting within glob bracket patterns be effective?

[Robert Elz]

Date:Thu, 12 Apr 2018 12:10:04 -0700
From:Don Cragun 
Message-ID:  

  | The fact that the $ is special is what is the key.

The problem is in the interpretation of just what "treated literally" means.

If it just means that "the character is itself and is not transformed into
something else" that's fine, the special $ inside the "" (which is not
treated literally, so it remains the introducer of various expansions)
can then look at the following character, see it is a '{' (untransformed)
and then go on and implement parameter expansion as you describe
-- and the various other characters that have meaning in that,
such as ':' '-' '+' '?' '%' '#' '=') which (being treated litterally all
represent themselves) can be part of the syntax.

On the other hand, if "treated literally" means "is itself and can have
no meaning or other interpretation other than being the character
itself" then that '{' must just be a '{' that is part of the string, and not
be co-opted into being part of the sh syntax for parameter expansions.

I am assuming here that the first interpretation is the desirable one.

Given that, then the "treated literally" '-' in the double quoted (or for
that matter single quoted) string inside a character class, is just a
'-' character, but that can still (as the '{' was in the parameter expansion)
be used as a syntax character in the class - indicating the range,
whether it was double quoted or not.

On the other hand, if you want the '-' to always represent the character
'-' itself, and not be part of the range expression, and you want to produce
that result just from the words "treated literally", you have to define
"treated literally" in the second form, and in that case, the '{' in the
"${..." form cannot be the '{' that is part of the parameter expansion.

It cannot be both ways.


But let me be clear about something - my point here is not to argue
for changes to all of the shells to meet some bizarre interpretation of
the specification, it is that the text in the standard needs to be improved,
and be explicit about things like this.

That it is possible for me to make an even semi-plausible argument in
this way means the text does not state the intentions nearly clearly
enough, and needs to be made much more precise.

There is a temptation for those who know what it should mean to read
the text, and see that it can mean what it should mean (and perhaps
not even notice that things could be interpreted differently) and then
be happy that all is OK.But when read by someone who has no idea
what the desired outcome is, and has only the words to reply upon,
we must be sure that there is no room at all for misinterpretation.

This is why standards are generally very dry, hard to read, and boring
documents - they need to be precise about every little detail (and yes,
saying something is unspecified or undefined is precise, provided it
is clear what the "something" is).

When 985 is revisited, and the wording for how pattern matching is done
gets revised, just specify all of this precisely - it does not need to be in the
form of some algorithm to achieve the desired result (although that is one
method) but it must make it absolutely clear what the desired result is,
for every possible input.

kre

Re: Should shell quoting within glob bracket patterns be effective?

[Don Cragun]

> On Apr 12, 2018, at 8:07 AM, Robert Elz  wrote:
> 
>Date:Thu, 12 Apr 2018 14:25:32 +0100
>From:Geoff Clare 
>Message-ID:  <20180412132532.GA9483@lt2.masqnet>
> 
>  | It treats them as literal characters, just as 2.2.3 says.
> 
> I thought that might have been the response, in that case in
> 
>   "${xxx}"
> 
> The '{' has to be treated as a literal character, as inside double
> quotes, and not being one of the magic few, that's what the text
> you quoted says, and apparently, everywhere else in the shell
> is supposed to follow that same interpretation.
> 
> That is, the '{' above cannot be treated the same as the one in
> 
>   ${xxx}
> 
> (unquoted) where it is a part of the syntax of the variable expansion,
> because then it would not be being treated literally.
> 
> Which way do you want it?
> 
> kre

The fact that the $ is special is what is the key.  Since $ is
special and parameter expansion and command substitution are
performed inside double-quotes, sections 2.6.2 and 2.6.3 come
into play... and that is where {, #, ##, %, %%, and } in
parameter expansions may become special and where ( and ) may
become special in command substitutions, respectively.

Cheers,
Don

[1003.1(2016)/Issue7+TC2 0001086]: Token "Recognition" is misleading and the usage of "word" in that section should be clarified.

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1086 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1086
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.3 Token Recognition 
Page Number:2347-2348 
Line Number:74742-74755 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Rejected
Fixed in Version:   
== 
Date Submitted: 2016-10-12 09:49 UTC
Last Modified:  2018-04-12 16:04 UTC
== 
Summary:Token "Recognition" is misleading and the usage of
"word" in that section should be clarified.
==
Relationships   ID  Summary
--
related to  0001100 Rewrite of Section 2.10 Shell Grammar, ...
== 

-- 
 (0003953) geoffclare (manager) - 2018-04-12 16:04
 http://austingroupbugs.net/view.php?id=1086#c3953 
-- 
Regarding the use of "word", note that it is a defined term.  See XBD 3.446
which says that in the shell command language, a word is "a token other
than an operator." 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-12 09:49 Mark_GaleckNew Issue
2016-10-12 09:49 Mark_GaleckName  => Mark Galeck 
2016-10-12 09:49 Mark_GaleckSection   => 2.3 Token
Recognition
2016-10-12 09:49 Mark_GaleckPage Number   => 2347-2348   
2016-10-12 09:49 Mark_GaleckLine Number   => 74742-74755 
2016-10-28 08:21 geoffclare Relationship added   related to 0001100  
2018-03-28 03:25 kreNote Added: 0003943  
2018-04-12 16:00 Don Cragun Interp Status => --- 
2018-04-12 16:00 Don Cragun Note Added: 0003952  
2018-04-12 16:00 Don Cragun Status   New => Closed   
2018-04-12 16:00 Don Cragun Resolution   Open => Rejected
2018-04-12 16:04 Don Cragun Note Edited: 0003952 
2018-04-12 16:04 geoffclare Note Added: 0003953  
==

[1003.1(2016)/Issue7+TC2 0001086]: Token "Recognition" is misleading and the usage of "word" in that section should be clarified.

[Austin Group Bug Tracker]

The following issue has been CLOSED. 
== 
http://austingroupbugs.net/view.php?id=1086 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1086
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.3 Token Recognition 
Page Number:2347-2348 
Line Number:74742-74755 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Rejected
Fixed in Version:   
== 
Date Submitted: 2016-10-12 09:49 UTC
Last Modified:  2018-04-12 16:00 UTC
== 
Summary:Token "Recognition" is misleading and the usage of
"word" in that section should be clarified.
==
Relationships   ID  Summary
--
related to  0001100 Rewrite of Section 2.10 Shell Grammar, ...
== 

-- 
 (0003952) Don Cragun (manager) - 2018-04-12 16:00
 http://austingroupbugs.net/view.php?id=1086#c3952 
-- 
We discussed this issue during the 2014-04-12 conference call and agree
with the comments in http://austingroupbugs.net/view.php?id=1086#c3943.  This
bug is rejected. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-12 09:49 Mark_GaleckNew Issue
2016-10-12 09:49 Mark_GaleckName  => Mark Galeck 
2016-10-12 09:49 Mark_GaleckSection   => 2.3 Token
Recognition
2016-10-12 09:49 Mark_GaleckPage Number   => 2347-2348   
2016-10-12 09:49 Mark_GaleckLine Number   => 74742-74755 
2016-10-28 08:21 geoffclare Relationship added   related to 0001100  
2018-03-28 03:25 kreNote Added: 0003943  
2018-04-12 16:00 Don Cragun Interp Status => --- 
2018-04-12 16:00 Don Cragun Note Added: 0003952  
2018-04-12 16:00 Don Cragun Status   New => Closed   
2018-04-12 16:00 Don Cragun Resolution   Open => Rejected
==

[1003.1(2016)/Issue7+TC2 0001098]: do_group symbol cannot be accepted as written, because rule 6 cannot yield Done token

[Austin Group Bug Tracker]

The following issue has been CLOSED. 
== 
http://austingroupbugs.net/view.php?id=1098 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1098
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2379 
Line Number:76091 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Withdrawn
Fixed in Version:   
== 
Date Submitted: 2016-10-20 16:56 UTC
Last Modified:  2018-04-12 15:41 UTC
== 
Summary:do_group symbol cannot be accepted as written,
because rule 6 cannot yield Done token
==
Relationships   ID  Summary
--
duplicate of0001100 Rewrite of Section 2.10 Shell Grammar, ...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-20 16:56 Mark_GaleckNew Issue
2016-10-20 16:56 Mark_GaleckName  => Mark Galeck 
2016-10-20 16:56 Mark_GaleckSection   => 2.10.2 Shell
Grammar Rules
2016-10-20 16:56 Mark_GaleckPage Number   => 2379
2016-10-20 16:56 Mark_GaleckLine Number   => 76091   
2016-10-21 09:23 geoffclare Note Added: 0003448  
2016-10-21 09:24 geoffclare Note Edited: 0003448 
2016-10-21 09:41 geoffclare Note Edited: 0003448 
2016-10-21 21:56 Mark_GaleckNote Added: 0003449  
2016-10-22 08:00 geoffclare Note Added: 0003450  
2016-10-22 08:22 Mark_GaleckNote Added: 0003451  
2016-10-22 10:44 geoffclare Note Added: 0003452  
2016-10-22 12:01 Mark_GaleckNote Added: 0003453  
2016-10-22 12:18 Mark_GaleckNote Added: 0003454  
2016-10-22 12:19 Mark_GaleckNote Edited: 0003454 
2016-10-22 12:19 Mark_GaleckNote Edited: 0003454 
2016-10-22 12:20 Mark_GaleckNote Edited: 0003454 
2016-10-22 12:24 Mark_GaleckNote Edited: 0003453 
2016-10-22 12:29 Mark_GaleckNote Added: 0003455  
2016-10-25 23:16 shware_systems Note Added: 0003457  
2016-10-26 16:32 Mark_GaleckNote Added: 0003458  
2016-10-26 16:39 Mark_GaleckNote Edited: 0003458 
2016-10-26 16:44 Mark_GaleckNote Edited: 0003458 
2016-10-26 16:46 Mark_GaleckNote Edited: 0003458 
2016-10-26 16:51 Mark_GaleckNote Edited: 0003458 
2016-10-27 12:45 Mark_GaleckNote Added: 0003466  
2016-10-28 08:22 geoffclare Relationship added   related to 0001100  
2018-04-12 15:40 eblake Relationship replacedduplicate of 0001100
2018-04-12 15:41 Don Cragun Interp Status => --- 
2018-04-12 15:41 Don Cragun Status   New => Closed   
2018-04-12 15:41 Don Cragun Resolution   Open => Withdrawn   
==

[1003.1(2016)/Issue7+TC2 0001098]: do_group symbol cannot be accepted as written, because rule 6 cannot yield Done token

[Austin Group Bug Tracker]

The following issue has been set as DUPLICATE OF issue 0001100. 
== 
http://austingroupbugs.net/view.php?id=1098 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1098
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2379 
Line Number:76091 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-20 16:56 UTC
Last Modified:  2016-10-28 08:22 UTC
== 
Summary:do_group symbol cannot be accepted as written,
because rule 6 cannot yield Done token
==
Relationships   ID  Summary
--
duplicate of0001100 Rewrite of Section 2.10 Shell Grammar, ...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-20 16:56 Mark_GaleckNew Issue
2016-10-20 16:56 Mark_GaleckName  => Mark Galeck 
2016-10-20 16:56 Mark_GaleckSection   => 2.10.2 Shell
Grammar Rules
2016-10-20 16:56 Mark_GaleckPage Number   => 2379
2016-10-20 16:56 Mark_GaleckLine Number   => 76091   
2016-10-21 09:23 geoffclare Note Added: 0003448  
2016-10-21 09:24 geoffclare Note Edited: 0003448 
2016-10-21 09:41 geoffclare Note Edited: 0003448 
2016-10-21 21:56 Mark_GaleckNote Added: 0003449  
2016-10-22 08:00 geoffclare Note Added: 0003450  
2016-10-22 08:22 Mark_GaleckNote Added: 0003451  
2016-10-22 10:44 geoffclare Note Added: 0003452  
2016-10-22 12:01 Mark_GaleckNote Added: 0003453  
2016-10-22 12:18 Mark_GaleckNote Added: 0003454  
2016-10-22 12:19 Mark_GaleckNote Edited: 0003454 
2016-10-22 12:19 Mark_GaleckNote Edited: 0003454 
2016-10-22 12:20 Mark_GaleckNote Edited: 0003454 
2016-10-22 12:24 Mark_GaleckNote Edited: 0003453 
2016-10-22 12:29 Mark_GaleckNote Added: 0003455  
2016-10-25 23:16 shware_systems Note Added: 0003457  
2016-10-26 16:32 Mark_GaleckNote Added: 0003458  
2016-10-26 16:39 Mark_GaleckNote Edited: 0003458 
2016-10-26 16:44 Mark_GaleckNote Edited: 0003458 
2016-10-26 16:46 Mark_GaleckNote Edited: 0003458 
2016-10-26 16:51 Mark_GaleckNote Edited: 0003458 
2016-10-27 12:45 Mark_GaleckNote Added: 0003466  
2016-10-28 08:22 geoffclare Relationship added   related to 0001100  
2018-04-12 15:40 eblake Relationship replacedduplicate of 0001100
==

[1003.1(2016)/Issue7+TC2 0001091]: Some "WORD tokens" do not have "the associated command"

[Austin Group Bug Tracker]

The following issue has been set as DUPLICATE OF issue 0001100. 
== 
http://austingroupbugs.net/view.php?id=1091 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1091
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.1 Shell Grammar Lexical Conventions 
Page Number:2375 
Line Number:75895-75896 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Withdrawn
Fixed in Version:   
== 
Date Submitted: 2016-10-18 11:55 UTC
Last Modified:  2016-10-27 18:19 UTC
== 
Summary:Some "WORD tokens" do not have "the associated
command"
==
Relationships   ID  Summary
--
duplicate of0001100 Rewrite of Section 2.10 Shell Grammar, ...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-18 11:55 Mark_GaleckNew Issue
2016-10-18 11:55 Mark_GaleckName  => Mark Galeck 
2016-10-18 11:55 Mark_GaleckSection   => 2.10.1 Shell
Grammar Lexical Conventions
2016-10-18 11:55 Mark_GaleckPage Number   => 2375
2016-10-18 11:55 Mark_GaleckLine Number   => 75895-75896 
2016-10-18 14:48 geoffclare Note Added: 0003419  
2016-10-18 15:04 Mark_GaleckNote Added: 0003421  
2016-10-18 15:28 Mark_GaleckNote Added: 0003425  
2016-10-18 15:55 geoffclare Note Added: 0003428  
2016-10-19 04:44 Mark_GaleckNote Added: 0003429  
2016-10-19 05:51 kreNote Added: 0003430  
2016-10-27 12:46 Mark_GaleckNote Added: 0003468  
2016-10-27 18:19 Don Cragun Interp Status => --- 
2016-10-27 18:19 Don Cragun Note Added: 0003479  
2016-10-27 18:19 Don Cragun Status   New => Closed   
2016-10-27 18:19 Don Cragun Resolution   Open => Withdrawn   
2018-04-12 15:39 eblake Relationship added   duplicate of 0001100
==

[1003.1(2016)/Issue7+TC2 0001100]: Rewrite of Section 2.10 Shell Grammar, of the Shell Standard, to fix previous reports, fix new issues, and improve presentation.

[Austin Group Bug Tracker]

The issue 0001098 has been set as DUPLICATE OF the following issue. 
== 
http://austingroupbugs.net/view.php?id=1100 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1100
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10 Shell Grammar 
Page Number:2375-2381 
Line Number:75873-76150 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-27 12:40 UTC
Last Modified:  2018-04-12 15:40 UTC
== 
Summary:Rewrite of Section 2.10 Shell Grammar, of the Shell
Standard, to fix previous reports, fix new issues, and improve presentation.
==
Relationships   ID  Summary
--
has duplicate   0001098 do_group symbol cannot be accepted as w...
has duplicate   0001088 When more than one rule applies, ...
has duplicate   0001091 Some WORD tokens do not hav...
has duplicate   0001093 or applies globally is poin...
related to  0001082 delimited is incorrect
related to  0001083 next character is misleading
related to  0001084 rule 3, 4, 5 do not say that a token is...
related to  0001085 token shall be from the current p...
related to  0001086 Token Recognition is mislea...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-27 12:40 Mark_GaleckNew Issue
2016-10-27 12:40 Mark_GaleckName  => Mark Galeck 
2016-10-27 12:40 Mark_GaleckSection   => 2.10 Shell Grammar
2016-10-27 12:40 Mark_GaleckPage Number   => 2375-2381   
2016-10-27 12:40 Mark_GaleckLine Number   => 75873-76150 
2016-10-27 12:57 Mark_GaleckNote Added: 0003470  
2016-10-28 08:19 geoffclare Relationship added   related to 0001082  
2016-10-28 08:20 geoffclare Relationship added   related to 0001083  
2016-10-28 08:20 geoffclare Relationship added   related to 0001084  
2016-10-28 08:21 geoffclare Relationship added   related to 0001085  
2016-10-28 08:21 geoffclare Relationship added   related to 0001086  
2016-10-28 08:22 geoffclare Relationship added   related to 0001098  
2018-03-28 03:59 kreNote Added: 0003944  
2018-04-12 15:38 eblake Relationship added   has duplicate 0001088
2018-04-12 15:39 eblake Relationship added   has duplicate 0001091
2018-04-12 15:39 eblake Relationship added   has duplicate 0001093
2018-04-12 15:40 eblake Relationship replacedhas duplicate 0001098
==

[1003.1(2016)/Issue7+TC2 0001093]: "or applies globally" is pointless

[Austin Group Bug Tracker]

The following issue has been set as DUPLICATE OF issue 0001100. 
== 
http://austingroupbugs.net/view.php?id=1093 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1093
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.2 Shell Grammar Rules 
Page Number:2375 
Line Number:75909-75910 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Withdrawn
Fixed in Version:   
== 
Date Submitted: 2016-10-18 12:07 UTC
Last Modified:  2016-10-27 18:18 UTC
== 
Summary:"or applies globally" is pointless
==
Relationships   ID  Summary
--
duplicate of0001100 Rewrite of Section 2.10 Shell Grammar, ...
related to  0001088 When more than one rule applies, ...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-18 12:07 Mark_GaleckNew Issue
2016-10-18 12:07 Mark_GaleckName  => Mark Galeck 
2016-10-18 12:07 Mark_GaleckSection   => 2.10.2 Shell
Grammar Rules
2016-10-18 12:07 Mark_GaleckPage Number   => 2375
2016-10-18 12:07 Mark_GaleckLine Number   => 75909-75910 
2016-10-19 09:17 kreNote Added: 0003432  
2016-10-19 10:52 Mark_GaleckNote Added: 0003436  
2016-10-19 13:45 Don Cragun Note Edited: 0003432 
2016-10-19 13:46 Don Cragun Note Edited: 0003432 
2016-10-19 13:46 Don Cragun Note Edited: 0003432 
2016-10-19 13:47 Don Cragun Note Edited: 0003436 
2016-10-19 15:48 nick   Relationship added   related to 0001088  
2016-10-27 12:46 Mark_GaleckNote Added: 0003467  
2016-10-27 18:18 Don Cragun Interp Status => --- 
2016-10-27 18:18 Don Cragun Note Added: 0003478  
2016-10-27 18:18 Don Cragun Status   New => Closed   
2016-10-27 18:18 Don Cragun Resolution   Open => Withdrawn   
2018-04-12 15:39 eblake Relationship added   duplicate of 0001100
==

[1003.1(2016)/Issue7+TC2 0001100]: Rewrite of Section 2.10 Shell Grammar, of the Shell Standard, to fix previous reports, fix new issues, and improve presentation.

[Austin Group Bug Tracker]

The issue 0001091 has been set as DUPLICATE OF the following issue. 
== 
http://austingroupbugs.net/view.php?id=1100 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1100
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10 Shell Grammar 
Page Number:2375-2381 
Line Number:75873-76150 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-27 12:40 UTC
Last Modified:  2018-04-12 15:39 UTC
== 
Summary:Rewrite of Section 2.10 Shell Grammar, of the Shell
Standard, to fix previous reports, fix new issues, and improve presentation.
==
Relationships   ID  Summary
--
has duplicate   0001088 When more than one rule applies, ...
has duplicate   0001091 Some WORD tokens do not hav...
related to  0001082 delimited is incorrect
related to  0001083 next character is misleading
related to  0001084 rule 3, 4, 5 do not say that a token is...
related to  0001085 token shall be from the current p...
related to  0001086 Token Recognition is mislea...
related to  0001098 do_group symbol cannot be accepted as w...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-27 12:40 Mark_GaleckNew Issue
2016-10-27 12:40 Mark_GaleckName  => Mark Galeck 
2016-10-27 12:40 Mark_GaleckSection   => 2.10 Shell Grammar
2016-10-27 12:40 Mark_GaleckPage Number   => 2375-2381   
2016-10-27 12:40 Mark_GaleckLine Number   => 75873-76150 
2016-10-27 12:57 Mark_GaleckNote Added: 0003470  
2016-10-28 08:19 geoffclare Relationship added   related to 0001082  
2016-10-28 08:20 geoffclare Relationship added   related to 0001083  
2016-10-28 08:20 geoffclare Relationship added   related to 0001084  
2016-10-28 08:21 geoffclare Relationship added   related to 0001085  
2016-10-28 08:21 geoffclare Relationship added   related to 0001086  
2016-10-28 08:22 geoffclare Relationship added   related to 0001098  
2018-03-28 03:59 kreNote Added: 0003944  
2018-04-12 15:38 eblake Relationship added   has duplicate 0001088
2018-04-12 15:39 eblake Relationship added   has duplicate 0001091
==

[1003.1(2016)/Issue7+TC2 0001100]: Rewrite of Section 2.10 Shell Grammar, of the Shell Standard, to fix previous reports, fix new issues, and improve presentation.

[Austin Group Bug Tracker]

The issue 0001093 has been set as DUPLICATE OF the following issue. 
== 
http://austingroupbugs.net/view.php?id=1100 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1100
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10 Shell Grammar 
Page Number:2375-2381 
Line Number:75873-76150 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-27 12:40 UTC
Last Modified:  2018-04-12 15:39 UTC
== 
Summary:Rewrite of Section 2.10 Shell Grammar, of the Shell
Standard, to fix previous reports, fix new issues, and improve presentation.
==
Relationships   ID  Summary
--
has duplicate   0001088 When more than one rule applies, ...
has duplicate   0001091 Some WORD tokens do not hav...
has duplicate   0001093 or applies globally is poin...
related to  0001082 delimited is incorrect
related to  0001083 next character is misleading
related to  0001084 rule 3, 4, 5 do not say that a token is...
related to  0001085 token shall be from the current p...
related to  0001086 Token Recognition is mislea...
related to  0001098 do_group symbol cannot be accepted as w...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-27 12:40 Mark_GaleckNew Issue
2016-10-27 12:40 Mark_GaleckName  => Mark Galeck 
2016-10-27 12:40 Mark_GaleckSection   => 2.10 Shell Grammar
2016-10-27 12:40 Mark_GaleckPage Number   => 2375-2381   
2016-10-27 12:40 Mark_GaleckLine Number   => 75873-76150 
2016-10-27 12:57 Mark_GaleckNote Added: 0003470  
2016-10-28 08:19 geoffclare Relationship added   related to 0001082  
2016-10-28 08:20 geoffclare Relationship added   related to 0001083  
2016-10-28 08:20 geoffclare Relationship added   related to 0001084  
2016-10-28 08:21 geoffclare Relationship added   related to 0001085  
2016-10-28 08:21 geoffclare Relationship added   related to 0001086  
2016-10-28 08:22 geoffclare Relationship added   related to 0001098  
2018-03-28 03:59 kreNote Added: 0003944  
2018-04-12 15:38 eblake Relationship added   has duplicate 0001088
2018-04-12 15:39 eblake Relationship added   has duplicate 0001091
2018-04-12 15:39 eblake Relationship added   has duplicate 0001093
==

[1003.1(2016)/Issue7+TC2 0001083]: "next" character is misleading

[Austin Group Bug Tracker]

The following issue has been RESOLVED. 
== 
http://austingroupbugs.net/view.php?id=1083 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1083
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: Resolved
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.3 Token Recognition 
Page Number:2347 
Line Number:74750 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Accepted
Fixed in Version:   
== 
Date Submitted: 2016-10-12 08:39 UTC
Last Modified:  2018-04-12 15:39 UTC
== 
Summary:"next" character is misleading
==
Relationships   ID  Summary
--
related to  0001100 Rewrite of Section 2.10 Shell Grammar, ...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-12 08:39 Mark_GaleckNew Issue
2016-10-12 08:39 Mark_GaleckName  => Mark Galeck 
2016-10-12 08:39 Mark_GaleckSection   => 2.3 Token
Recognition
2016-10-12 08:39 Mark_GaleckPage Number   => 2347
2016-10-12 08:39 Mark_GaleckLine Number   => 74750   
2016-10-28 08:20 geoffclare Relationship added   related to 0001100  
2018-04-12 15:39 nick   Interp Status => --- 
2018-04-12 15:39 nick   Status   New => Resolved 
2018-04-12 15:39 nick   Resolution   Open => Accepted
==

[1003.1(2016)/Issue7+TC2 0001100]: Rewrite of Section 2.10 Shell Grammar, of the Shell Standard, to fix previous reports, fix new issues, and improve presentation.

[Austin Group Bug Tracker]

The issue 0001088 has been set as DUPLICATE OF the following issue. 
== 
http://austingroupbugs.net/view.php?id=1100 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1100
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10 Shell Grammar 
Page Number:2375-2381 
Line Number:75873-76150 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-27 12:40 UTC
Last Modified:  2018-04-12 15:38 UTC
== 
Summary:Rewrite of Section 2.10 Shell Grammar, of the Shell
Standard, to fix previous reports, fix new issues, and improve presentation.
==
Relationships   ID  Summary
--
has duplicate   0001088 When more than one rule applies, ...
related to  0001082 delimited is incorrect
related to  0001083 next character is misleading
related to  0001084 rule 3, 4, 5 do not say that a token is...
related to  0001085 token shall be from the current p...
related to  0001086 Token Recognition is mislea...
related to  0001098 do_group symbol cannot be accepted as w...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-27 12:40 Mark_GaleckNew Issue
2016-10-27 12:40 Mark_GaleckName  => Mark Galeck 
2016-10-27 12:40 Mark_GaleckSection   => 2.10 Shell Grammar
2016-10-27 12:40 Mark_GaleckPage Number   => 2375-2381   
2016-10-27 12:40 Mark_GaleckLine Number   => 75873-76150 
2016-10-27 12:57 Mark_GaleckNote Added: 0003470  
2016-10-28 08:19 geoffclare Relationship added   related to 0001082  
2016-10-28 08:20 geoffclare Relationship added   related to 0001083  
2016-10-28 08:20 geoffclare Relationship added   related to 0001084  
2016-10-28 08:21 geoffclare Relationship added   related to 0001085  
2016-10-28 08:21 geoffclare Relationship added   related to 0001086  
2016-10-28 08:22 geoffclare Relationship added   related to 0001098  
2018-03-28 03:59 kreNote Added: 0003944  
2018-04-12 15:38 eblake Relationship added   has duplicate 0001088
==

[1003.1(2016)/Issue7+TC2 0001088]: "When more than one rule applies, the highest numbered rule shall apply " is pointless

[Austin Group Bug Tracker]

The following issue has been set as DUPLICATE OF issue 0001100. 
== 
http://austingroupbugs.net/view.php?id=1088 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1088
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.10.1 Shell Grammar Lexical Conventions 
Page Number:2375 
Line Number:75892-75893 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Withdrawn
Fixed in Version:   
== 
Date Submitted: 2016-10-18 10:58 UTC
Last Modified:  2016-10-27 18:20 UTC
== 
Summary:"When more than one rule applies, the highest
numbered rule shall apply " is pointless
==
Relationships   ID  Summary
--
duplicate of0001100 Rewrite of Section 2.10 Shell Grammar, ...
related to  0001093 or applies globally is poin...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-18 10:58 Mark_GaleckNew Issue
2016-10-18 10:58 Mark_GaleckName  => Mark Galeck 
2016-10-18 10:58 Mark_GaleckSection   => 2.10.1 Shell
Grammar Lexical Conventions
2016-10-18 10:58 Mark_GaleckPage Number   => 2375
2016-10-18 10:58 Mark_GaleckLine Number   => 75892-75893 
2016-10-19 09:17 kreNote Added: 0003431  
2016-10-19 10:49 Mark_GaleckNote Added: 0003435  
2016-10-19 15:48 nick   Relationship added   related to 0001093  
2016-10-27 12:46 Mark_GaleckNote Added: 0003469  
2016-10-27 18:20 Don Cragun Interp Status => --- 
2016-10-27 18:20 Don Cragun Note Added: 0003480  
2016-10-27 18:20 Don Cragun Status   New => Closed   
2016-10-27 18:20 Don Cragun Resolution   Open => Withdrawn   
2018-04-12 15:38 eblake Relationship added   duplicate of 0001100
==

[1003.1(2016)/Issue7+TC2 0001082]: "delimited" is incorrect

[Austin Group Bug Tracker]

The following issue has been CLOSED. 
== 
http://austingroupbugs.net/view.php?id=1082 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1082
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Mark Galeck 
Organization:
User Reference:  
Section:2.3 Token Recognition 
Page Number:2347-2348 
Line Number:74751-74792 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Rejected
Fixed in Version:   
== 
Date Submitted: 2016-10-12 08:08 UTC
Last Modified:  2018-04-12 15:36 UTC
== 
Summary:"delimited" is incorrect
==
Relationships   ID  Summary
--
related to  0001100 Rewrite of Section 2.10 Shell Grammar, ...
== 

-- 
 (0003951) nick (manager) - 2018-04-12 15:36
 http://austingroupbugs.net/view.php?id=1082#c3951 
-- 
As stated in http://austingroupbugs.net/view.php?id=1082#c3406 we believe that
the current wording is
sufficiently clear and the use of the term is clearly stated in the
previous paragraph.  

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-12 08:08 Mark_GaleckNew Issue
2016-10-12 08:08 Mark_GaleckName  => Mark Galeck 
2016-10-12 08:08 Mark_GaleckSection   => 2.3 Token
Recognition
2016-10-12 08:08 Mark_GaleckPage Number   => 2347-2348   
2016-10-12 08:08 Mark_GaleckLine Number   => 74751-74792 
2016-10-12 11:58 kreNote Added: 0003406  
2016-10-12 13:52 Mark_GaleckNote Added: 0003407  
2016-10-28 08:19 geoffclare Relationship added   related to 0001100  
2018-04-12 15:36 nick   Interp Status => --- 
2018-04-12 15:36 nick   Note Added: 0003951  
2018-04-12 15:36 nick   Status   New => Closed   
2018-04-12 15:36 nick   Resolution   Open => Rejected
==

[1003.1(2016)/Issue7+TC2 0001081]: sysconf shading error on obsolete system variables

[Austin Group Bug Tracker]

The following issue has been CLOSED. 
== 
http://austingroupbugs.net/view.php?id=1081 
== 
Reported By:markh
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1081
Category:   System Interfaces
Type:   Error
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Mark Harris 
Organization:
User Reference:  
Section:sysconf() 
Page Number:2101 
Line Number:67354-67358 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Accepted
Fixed in Version:   
== 
Date Submitted: 2016-10-08 06:45 UTC
Last Modified:  2018-04-12 15:16 UTC
== 
Summary:sysconf shading error on obsolete system variables
== 

-- 
 (0003950) geoffclare (manager) - 2018-04-12 15:16
 http://austingroupbugs.net/view.php?id=1081#c3950 
-- 
This has been fixed in more recent versions. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-08 06:45 markh  New Issue
2016-10-08 06:45 markh  Name  => Mark Harris 
2016-10-08 06:45 markh  Section   => sysconf()   
2016-10-08 06:45 markh  Page Number   => 2101
2016-10-08 06:45 markh  Line Number   => 67354-67358 
2016-10-10 08:44 geoffclare Project  2008-TC2 =>
1003.1(2016)/Issue7+TC2
2016-10-10 08:51 geoffclare Note Added: 0003404  
2018-04-12 15:16 geoffclare Interp Status => --- 
2018-04-12 15:16 geoffclare Note Added: 0003950  
2018-04-12 15:16 geoffclare Status   New => Closed   
2018-04-12 15:16 geoffclare Resolution   Open => Accepted
==

[Online Pubs 0001080]: Misplaced "Chapter 7, Locale"

[Austin Group Bug Tracker]

The following issue has been CLOSED. 
== 
http://austingroupbugs.net/view.php?id=1080 
== 
Reported By:dannyniu
Assigned To:
== 
Project:Online Pubs
Issue ID:   1080
Category:   Rationale
Type:   Error
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   DannyNiu/NJF 
Organization:
User Reference:  
URL:   
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap04.html 
Section:C.4.3 Exclusion of Utilities 
Resolution: Accepted
Fixed in Version:   
== 
Date Submitted: 2016-10-07 09:06 UTC
Last Modified:  2018-04-12 15:13 UTC
== 
Summary:Misplaced "Chapter 7, Locale"
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-07 09:06 dannyniu   New Issue
2016-10-07 09:06 dannyniu   Name  => DannyNiu/NJF
2016-10-07 09:06 dannyniu   URL   =>
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap04.html
2016-10-07 09:06 dannyniu   Section   => C.4.3 Exclusion of
Utilities
2016-10-07 10:51 ajosey Note Added: 0003402  
2018-04-12 15:13 geoffclare Status   New => Closed   
2018-04-12 15:13 geoffclare Resolution   Open => Accepted
==

[1003.1(2008)/Issue 7 0001079]: focus on bc being an arithmetic language

[Austin Group Bug Tracker]

The following issue has been CLOSED. 
== 
http://austingroupbugs.net/view.php?id=1079 
== 
Reported By:tobiasm
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   1079
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Tobias Martens 
Organization:
User Reference:  
Section:bc 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Rejected
Fixed in Version:   
== 
Date Submitted: 2016-10-05 23:40 UTC
Last Modified:  2018-04-12 15:12 UTC
== 
Summary:focus on bc being an arithmetic language
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-05 23:40 tobiasmNew Issue
2016-10-05 23:40 tobiasmStatus   New => Under Review 
2016-10-05 23:40 tobiasmAssigned To   => ajosey  
2016-10-05 23:40 tobiasmName  => Tobias Martens  
2016-10-05 23:40 tobiasmSection   => bc  
2016-10-05 23:40 tobiasmPage Number   => -   
2016-10-05 23:40 tobiasmLine Number   => -   
2016-10-06 07:41 Vincent LefevreNote Added: 0003395  
2016-10-06 07:41 Vincent LefevreNote Edited: 0003395 
2016-10-06 07:42 Vincent LefevreNote Edited: 0003395 
2016-10-06 08:02 Vincent LefevreNote Edited: 0003395 
2016-10-06 08:09 Vincent LefevreNote Added: 0003396  
2016-10-06 10:19 stephane   Note Added: 0003397  
2016-10-06 10:21 stephane   Note Edited: 0003397 
2016-10-06 10:39 stephane   Note Edited: 0003397 
2016-10-06 23:05 tobiasmNote Added: 0003398  
2016-10-07 00:06 Vincent LefevreNote Added: 0003399  
2016-10-07 00:15 Vincent LefevreNote Added: 0003400  
2016-10-07 02:14 Don Cragun Note Added: 0003401  
2016-10-07 22:44 tobiasmNote Added: 0003403  
2018-03-28 03:08 kreNote Added: 0003942  
2018-04-12 15:11 Don Cragun Note Added: 0003949  
2018-04-12 15:12 Don Cragun Interp Status => --- 
2018-04-12 15:12 Don Cragun Status   Under Review => Closed
2018-04-12 15:12 Don Cragun Resolution   Open => Rejected
==

[1003.1(2008)/Issue 7 0001079]: focus on bc being an arithmetic language

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1079 
== 
Reported By:tobiasm
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   1079
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Under Review
Name:   Tobias Martens 
Organization:
User Reference:  
Section:bc 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-10-05 23:40 UTC
Last Modified:  2018-04-12 15:11 UTC
== 
Summary:focus on bc being an arithmetic language
== 

-- 
 (0003949) Don Cragun (manager) - 2018-04-12 15:11
 http://austingroupbugs.net/view.php?id=1079#c3949 
-- 
After discussing this bug on the 2018-04-12 conference call, we decided to
reject this issue for the reasons stated in
http://austingroupbugs.net/view.php?id=1079#c3401. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-10-05 23:40 tobiasmNew Issue
2016-10-05 23:40 tobiasmStatus   New => Under Review 
2016-10-05 23:40 tobiasmAssigned To   => ajosey  
2016-10-05 23:40 tobiasmName  => Tobias Martens  
2016-10-05 23:40 tobiasmSection   => bc  
2016-10-05 23:40 tobiasmPage Number   => -   
2016-10-05 23:40 tobiasmLine Number   => -   
2016-10-06 07:41 Vincent LefevreNote Added: 0003395  
2016-10-06 07:41 Vincent LefevreNote Edited: 0003395 
2016-10-06 07:42 Vincent LefevreNote Edited: 0003395 
2016-10-06 08:02 Vincent LefevreNote Edited: 0003395 
2016-10-06 08:09 Vincent LefevreNote Added: 0003396  
2016-10-06 10:19 stephane   Note Added: 0003397  
2016-10-06 10:21 stephane   Note Edited: 0003397 
2016-10-06 10:39 stephane   Note Edited: 0003397 
2016-10-06 23:05 tobiasmNote Added: 0003398  
2016-10-07 00:06 Vincent LefevreNote Added: 0003399  
2016-10-07 00:15 Vincent LefevreNote Added: 0003400  
2016-10-07 02:14 Don Cragun Note Added: 0003401  
2016-10-07 22:44 tobiasmNote Added: 0003403  
2018-03-28 03:08 kreNote Added: 0003942  
2018-04-12 15:11 Don Cragun Note Added: 0003949  
==

Re: Should shell quoting within glob bracket patterns be effective?

[Robert Elz]

Date:Thu, 12 Apr 2018 14:25:32 +0100
From:Geoff Clare 
Message-ID:  <20180412132532.GA9483@lt2.masqnet>

  | It treats them as literal characters, just as 2.2.3 says.

I thought that might have been the response, in that case in

"${xxx}"

The '{' has to be treated as a literal character, as inside double
quotes, and not being one of the magic few, that's what the text
you quoted says, and apparently, everywhere else in the shell
is supposed to follow that same interpretation.

That is, the '{' above cannot be treated the same as the one in

${xxx}

(unquoted) where it is a part of the syntax of the variable expansion,
because then it would not be being treated literally.

Which way do you want it?

kre

Re: Should shell quoting within glob bracket patterns be effective?

[Geoff Clare]

Robert Elz  wrote, on 12 Apr 2018:
>
> Date:Thu, 12 Apr 2018 13:25:01 +0100
> From:Geoff Clare 
> 
>   | Yes there is.  I quoted it earlier in this thread.
> 
> I know that, but that's useless for this purpose.   We know the quoted
> (part of) the string is treated literally, and handed to the pattern matching 
> code,
> exactly as is, with no conversions performed upon it.
> 
> But now what is the pattern matching code supposed to do with that
> string?

It treats them as literal characters, just as 2.2.3 says.

> Where does it say (aside from the 985 resolution) that those characters
> mean anything different in a pattern than they would in a pattern given
> anywhere else?

The statement "shall preserve the literal value of all characters" in
2.2.3 is sufficient.

> Eg: if I do
> 
>   find . -name '[a-z]*' -print
> 
> are you suggesting that because that '[' '-' and '*' are qoted they are not to
> be given their normal pattern (class, range and "all") meanings ?

The shell passes the literal characters [a-z]* to find.  What find
does with those is specified in the description of find.

> Obviously not.
> 
> What about
> 
>   find . -name '"[a-z]*"' -print?

The shell passes the literal characters "[a-z]*" to find.  What find
does with those is specified in the description of find.

> So in
> 
>   ls "[a-z]*"
> 
> given that quote removal is not performed before the filename expansion,
> exactly what text in the standard says the quotes should be treated 
> differently
> in this than in the 2nd find example above?

The shell passes the literal characters [a-z]* to ls.  What ls does
with those is specified in the description of ls.

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

Re: Should shell quoting within glob bracket patterns be effective?

[Robert Elz]

Date:Thu, 12 Apr 2018 13:25:01 +0100
From:Geoff Clare 
Message-ID:  <20180412122501.GA8783@lt2.masqnet>

  | Yes there is.  I quoted it earlier in this thread.

I know that, but that's useless for this purpose.   We know the quoted
(part of) the string is treated literally, and handed to the pattern matching 
code,
exactly as is, with no conversions performed upon it.

But now what is the pattern matching code supposed to do with that
string?

Where does it say (aside from the 985 resolution) that those characters
mean anything different in a pattern than they would in a pattern given
anywhere else?

Eg: if I do

find . -name '[a-z]*' -print

are you suggesting that because that '[' '-' and '*' are qoted they are not to
be given their normal pattern (class, range and "all") meanings ?

Obviously not.

What about

find . -name '"[a-z]*"' -print?

There quotes get handed to find as part of the arg, but quotes mean nothing
to pattern matching normally, so this one should look for file names that begin
and end with double quote characters, and have a lower-case alpha as the
first character after the leading ".   Right?

So in

ls "[a-z]*"

given that quote removal is not performed before the filename expansion,
exactly what text in the standard says the quotes should be treated differently
in this than in the 2nd find example above?

Note in all of this I am not questioning what should be done, or what shells
actually do, but rather how I work out from the text in the standard what
should be done.

kre

Re: Should shell quoting within glob bracket patterns be effective?

[Geoff Clare]

Robert Elz  wrote, on 12 Apr 2018:
>
> Date:Thu, 12 Apr 2018 11:39:11 +0100
> From:Geoff Clare 
> 
>   | Huh?  The '-' is quoted by the double quotes and should therefore be
>   | treated literally. 
> 
> The problem is that there is nothing in either TC2 or TC2 + 985-fix that
> says that should happen.

Yes there is.  I quoted it earlier in this thread.

2.2.3 Double-Quotes

Enclosing characters in double-quotes ("") shall preserve the literal
value of all characters within the double-quotes, with the exception
of the characters backquote, , and 

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

Re: Should shell quoting within glob bracket patterns be effective?

[Robert Elz]

Date:Thu, 12 Apr 2018 11:39:11 +0100
From:Geoff Clare 
Message-ID:  <20180412103911.GA6656@lt2.masqnet>

  | Huh?  The '-' is quoted by the double quotes and should therefore be
  | treated literally. 

The problem is that there is nothing in either TC2 or TC2 + 985-fix that
says that should happen.   And without that "should" is really just
wishing (based upon what shells actually do, or most of them).

The issue is how to specify it so that everything works correctly, for
all the cases of sh pattern matching, and for the other users of fnmatch()

Ideally:
find dir -name 'pattern' -print
should list the same filenames (in a different order/format) as
ls dir/pattern
lists, for all possible patterns (temporarily ignoring leading
dot issues, if there are any), and
ls dir | while read f
  do case "$f" in (pattern) printf '%s\n' "$f";;
  esac; done
should (again, ignoring '.' issues for now) print the same list.


kre

Re: Should shell quoting within glob bracket patterns be effective?

[Robert Elz]

Date:Thu, 12 Apr 2018 12:10:20 +0200
From:Joerg Schilling 
Message-ID:  <5acf308c.yoyva4vzwwu8t7jp%joerg.schill...@fokus.fraunhofer.de>

Jörg:

  | Since '' and "" quoting in the shell is highly complex and no longer 
present at 
  | the time the shell pattern matching is called,

That's not correct (well, "highly complex" is reasonable) at least
according to the standard (rather than how things might be
implemented in any particular implementation)

In filenames, the order is tilde expansion, (field splitting is irrelevant
for present purposes), parameter expansion (and its companions)
filename expansion, and finally, quote removal.See "The order of
word expansions" and what follows in XCU 2.6.

If it were not that way, then ls "*"* would not find files starting with a 
literal 
asterisk, but just all files.

In case patterns the old (current) standard does no quote removal on
the pattern at all - 985 tries to fix that but doesn't get it right.

In parameter expansions, the % and # (and %% and ## of course)
operators also happen before quote removal, so the pattern matching
they do also still has the quote characters.   Of course, for these ones
the standard says nothing at all about what "matched by pattern" means
and just assumes "you know it is a glob style match" and what that
means (and we all do it by comparing results from other shells and
hoping we haven't missed any weird cases...)

Are there any other uses of patterns in (standard) sh?  I can't remember
any right now/

  |  it makes no sense to add '' and "" to fnmatch().

That might be true, but assuming that we want fnmatch() to produce
the same results as sh does (given the correct flags to indicate what
kind of match it should perform) we would need to be very specific
about exactly how to translate a quoted shell string into a fnmatch
pattern.

  | To understand quoting, let me explain how the Bourne Shell does it:

Once again, this is (kind of) interesting but 100% irrelevant.

What matters is what the standard says must be done, not how some
implementation chooses to implement that.   One thing the standard
does not say that should be done is to convert one form of quoting
into another form (ever, except for the 985 bug resolution I think.)

Of course, provided the results are correct, it is fine to do that
within an implementation (ash based shells do quoting a totally
different way, but also not the posix "leave the quotes in the word")
but it is unacceptable to assume that all other implementations
must, or should, act that way - or even that their implementors
would ever consider doing it that way.

As long as posix says to leave the quotes in the word until
quote removal, and as long as quote removal happens after
pattern matching (or filename expansion for that case) the
specification of the pattern matching algorithm must handle '
and " chars in the pattern.

And if the pattern matching algorithm is just to be "call
fnmatch() with the flags..." (etc) then fnmatch needs to
handle them as well.   Alternatively, the algorithm could
be "convert quoted strings in the pattern as ..[to be
completed].. and then call fnmatch() using the modified
pattern, then fnmatch does not need to handle quotes.

Which is better largely depends upon just how flexible we
want the fnmatch() function to be - that is, must all callers
deal with quoting (if their context allows that) somehow,
before calling it ?

What the standard specifies should however match what the
implementations actually do (or at least most of them.)

kre

ps: it was interesting to see that the (ancient algol68 style) code
fragment you sent in the earlier message did not handle a ']'
as the first char of a class correctly (meaning a ']' in the class
instead of being the ending delimiter).   I don't remember ever
encountering that issue back when I used that shell - of course
wanting ']' in c char class is not common, so it is perhaps not
too surprising.   And wrt that message - for persent purposes,
it would be better to run tests using case pattern matching rather
than filename expansion - for filename expansion it is quite clear
that quote removal happens after the pattern matching, so the
shell is free to interpret the quote chars.  For case patterns it
is not so clear what should be done.

Re: Should shell quoting within glob bracket patterns be effective?

[Joerg Schilling]

Geoff Clare  wrote:

> > 
> > > ["a\-c"] the backslash is not special and should be treated literally
> > 
> > This string is converted into [\a\\-\c] by the shell macro expansion code.
> > 
> > With the shell gmatch() code, this results in a match for 'a' and '\\' .. 
> > 'c'.
>
> Huh?  The '-' is quoted by the double quotes and should therefore be
> treated literally.  It should match only 'a', backslash, '-' and 'c'
> (and that's what I observe in bash, although ksh88 for some reason only
> matches 'a', backslash and 'c' which looks like a bug).

You are right, Sorry, I missed one backslash before the '-'. The resulting 
pattern
is: [\a\\\-\c]

Here is an updated script "tsh":

-
if [ "$BASH_VERSION" != "" ]; then
echo() { command echo -e "$@"; }
fi

chk() { echo [a-c] ["a-c"] ["a\-c"] [\a\-\c] [a\-c]; }

mkdir td && cd td || exit

printf '%s\n' '---> [a-c] ["a-c"] ["a\-c"] [\a\-\c] [a\-c]'

echo ":  \c"; chk

:> a; echo "a: \c"; chk; rm a

:> b; echo "b: \c"; chk; rm b

:> ./-; echo "-: \c"; chk; rm ./-

:> c; echo "c: \c"; chk; rm c

:> _; echo "_: \c"; chk; rm _

:> \\; echo "\\: \c"; chk; rm \\

:> d; echo "d: \c"; chk; rm d

rm -f *
cd ..
rmdir td
-

and with:

for i in sh ksh ksh93 bosh bash mksh dash; do echo; echo $i:; $i ./tsh; 
done 

you get this result:

sh:
---> [a-c] ["a-c"] ["a\-c"] [\a\-\c] [a\-c]
:  [a-c] [a-c] [a\-c] [a-c] [a-c]
a: a a a a a
b: b [a-c] [a\-c] [a-c] [a-c]
-: [a-c] - - - -
c: c c c c c
_: [a-c] [a-c] [a\-c] [a-c] [a-c]
\: [a-c] [a-c] \ [a-c] [a-c]
d: [a-c] [a-c] [a\-c] [a-c] [a-c]

ksh:
---> [a-c] ["a-c"] ["a\-c"] [\a\-\c] [a\-c]
:  [a-c] [a-c] [a\-c] [a-c] [a-c]
a: a a a a a
b: b [a-c] [a\-c] [a-c] b
-: [a-c] [a-c] [a\-c] [a-c] [a-c]
c: c c c c c
_: [a-c] [a-c] [a\-c] [a-c] [a-c]
\: [a-c] \ \ \ \
d: [a-c] [a-c] [a\-c] [a-c] [a-c]

ksh93:
---> [a-c] ["a-c"] ["a\-c"] [\a\-\c] [a\-c]
:  [a-c] [a-c] [a\-c] [a-c] [a-c]
a: a a a a a
b: b b b [a-c] [a-c]
-: [a-c] [a-c] [a\-c] - -
c: c c c c c
_: [a-c] [a-c] [a\-c] [a-c] [a-c]
\: [a-c] [a-c] \ [a-c] [a-c]
d: [a-c] [a-c] [a\-c] [a-c] [a-c]

bosh:
---> [a-c] ["a-c"] ["a\-c"] [\a\-\c] [a\-c]
:  [a-c] [a-c] [a\-c] [a-c] [a-c]
a: a a a a a
b: b [a-c] [a\-c] [a-c] [a-c]
-: [a-c] - - - -
c: c c c c c
_: [a-c] [a-c] [a\-c] [a-c] [a-c]
\: [a-c] [a-c] \ [a-c] [a-c]
d: [a-c] [a-c] [a\-c] [a-c] [a-c]

bash:
---> [a-c] ["a-c"] ["a\-c"] [\a\-\c] [a\-c]
:  [a-c] [a-c] [a\-c] [a-c] [a-c]
a: a a a a a
b: b [a-c] [a\-c] [a-c] [a-c]
-: [a-c] - - - -
c: c c c c c
_: [a-c] [a-c] [a\-c] [a-c] [a-c]
\: [a-c] [a-c] \ [a-c] [a-c]
d: [a-c] [a-c] [a\-c] [a-c] [a-c]

mksh:
---> [a-c] ["a-c"] ["a\-c"] [\a\-\c] [a\-c]
:  [a-c] [a-c] [a\-c] [a-c] [a-c]
a: a a a a a
b: b [a-c] [a\-c] [a-c] [a-c]
-: [a-c] - - - -
c: c c c c c
_: [a-c] [a-c] [a\-c] [a-c] [a-c]
\: [a-c] [a-c] \ [a-c] [a-c]
d: [a-c] [a-c] [a\-c] [a-c] [a-c]

dash:
---> [a-c] ["a-c"] ["a\-c"] [\a\-\c] [a\-c]
:  [a-c] [a-c] [a\-c] [a-c] [a-c]
a: a a a a a
b: b [a-c] b [a-c] [a-c]
-: [a-c] - [a\-c] - -
c: c c c c c
_: [a-c] [a-c] _ [a-c] [a-c]
\: [a-c] [a-c] \ [a-c] [a-c]
d: [a-c] [a-c] [a\-c] [a-c] [a-c]

So there is a new bug in "dash", as dash matches '_' for your example
and '_' is inside the range '\\' .. 'c'.

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

Re: Should shell quoting within glob bracket patterns be effective?

[Geoff Clare]

Joerg Schilling  wrote, on 12 Apr 2018:
>
> Geoff Clare  wrote:
> 
> > > Maybe, I should again mention history:
> > > 
> > >   -   fmnatch() has been introduced with issue 4 (1995). It does not
> > >   seem to be related to a historic UNIX. Since the oldest known
> > >   implementation is from IBM, fnmatch() may have been introduced
> > >   by AIX.
> >
> > It was first standardised in POSIX.2-1992 and was invented by the developers
> > of that standard.
> 
> So fnmatch() could be seen as an artificial invention and there is no need to 
> have fnmatch() to behave the same as the shell. 

It performs filename/pathname pattern matching as done by find and pax.
It is only the same as the shell when there is no shell quoting involved.

> > You are conflating two different type of backslash escape.
> >
> > The shell should honour backslash when used as shell quoting, regardless
> > of whether it is inside a bracket expression, but should not treat a
> > backslash in a bracket expression *that is part of the pattern* (i.e. not
> > shell quoting) as special.
> >
> > For example:
> >
> > [\"] the backslash quotes the "
> 
> This string is converted to [\"] by the parser and there is no PS2 prompt.
> 
> 
> > ["a\-c"] the backslash is not special and should be treated literally
> 
> This string is converted into [\a\\-\c] by the shell macro expansion code.
> 
> With the shell gmatch() code, this results in a match for 'a' and '\\' .. 'c'.

Huh?  The '-' is quoted by the double quotes and should therefore be
treated literally.  It should match only 'a', backslash, '-' and 'c'
(and that's what I observe in bash, although ksh88 for some reason only
matches 'a', backslash and 'c' which looks like a bug).

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

Re: Should shell quoting within glob bracket patterns be effective?

[Joerg Schilling]

Geoff Clare  wrote:

> > Maybe, I should again mention history:
> > 
> > -   fmnatch() has been introduced with issue 4 (1995). It does not
> > seem to be related to a historic UNIX. Since the oldest known
> > implementation is from IBM, fnmatch() may have been introduced
> > by AIX.
>
> It was first standardised in POSIX.2-1992 and was invented by the developers
> of that standard.

So fnmatch() could be seen as an artificial invention and there is no need to 
have fnmatch() to behave the same as the shell. 

It would however be nive to be able to switch it into that mode (see my 
FNM_CLASSESC proposal.

> You are conflating two different type of backslash escape.
>
> The shell should honour backslash when used as shell quoting, regardless
> of whether it is inside a bracket expression, but should not treat a
> backslash in a bracket expression *that is part of the pattern* (i.e. not
> shell quoting) as special.
>
> For example:
>
> [\"] the backslash quotes the "

This string is converted to [\"] by the parser and there is no PS2 prompt.


> ["a\-c"] the backslash is not special and should be treated literally

This string is converted into [\a\\-\c] by the shell macro expansion code.

With the shell gmatch() code, this results in a match for 'a' and '\\' .. 'c'.

So I guess that you missinterpret my text and the results from my test script.

Let me add an updated version that includes a test for "-":

mkdir td && cd td || exit

:> a
echo [a-c] ["a-c"] [\a\-\c] [a\-c]
rm a

:> b
echo [a-c] ["a-c"] [\a\-\c] [a\-c]
rm b

:> ./-
echo [a-c] ["a-c"] [\a\-\c] [a\-c]
rm ./-

:> c
echo [a-c] ["a-c"] [\a\-\c] [a\-c]
rm c

:> _
echo [a-c] ["a-c"] [\a\-\c] [a\-c]
rm _

:> \\
echo [a-c] ["a-c"] [\a\-\c] [a\-c]
rm \\

:> d
echo [a-c] ["a-c"] [\a\-\c] [a\-c]
rm d

rm -f *
cd ..
rmdir td

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

Re: Should shell quoting within glob bracket patterns be effective?

[Joerg Schilling]

Robert Elz  wrote:

> And yes, in particular if a [a\-c] means a class with the three chars 'a' '-'
> and 'c' in it in sh it should mean that in fnmatch() as well, or if that 
> pattern means a class with 8 chars (0x5c .. 0x63) with 'a' there 2 ways,
> in fnmatch() then it should mean that in sh as well. 

My tests verify that all modern shells including ksh93 match three chars for
[a\-c]

> On the other hand, having sh allow '' and "" quoting in addition to \ quoting
> while not supporting that in fnmatch() is possible using a technique like
> that in what was intended to be the 985 resolution - just provided that it
> handles all of the cases correctly.

Since '' and "" quoting in the shell is highly complex and no longer present at 
the time the shell pattern matching is called, it makes no sense to add '' and 
"" to fnmatch().

To understand quoting, let me explain how the Bourne Shell does it:

1)  the parser keeps \a and converts 'a' into \a

2)  The parser retains " in strings

3)  The interpreter calls the macro expansion code and this code
replaces the extended strings inside "" by quote chars (e.g. "abc"
into \a\b\c).

4)  The file name globbing is done for command arguments and gmatch()
is called for "case" statements, using the current state of the string
that reaults in:

\aq\o\oq\a\b\c

for

'a'q'oo'q"abc"

If you like to let fnmatch() match the behavior of the shell related to 
character classes, this could be cone using a new flag FNM_CLASSESC.

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

Re: Should shell quoting within glob bracket patterns be effective?

[Geoff Clare]

Joerg Schilling  wrote, on 12 Apr 2018:
>
> It seems that we need to define how quoting works in a real shell 
> implementation. 
> 
> If we require the strings to be in the form \c\h\a\r in case of a quoted 
> string 
> at that specific part of the shell, we may explain how quoting works for 
> "case"
> statements.
> 
> Maybe, I should again mention history:
> 
>   -   fmnatch() has been introduced with issue 4 (1995). It does not
>   seem to be related to a historic UNIX. Since the oldest known
>   implementation is from IBM, fnmatch() may have been introduced
>   by AIX.

It was first standardised in POSIX.2-1992 and was invented by the developers
of that standard.

[...] 
> Now let us check the behavior of various shells with the following script:
> 

[...]
> As we can see:
> 
> - The Bourne Shell interprets backshlash escapes
>   inside character classes.
> 
> - All other (relevant) shells behave identically
>   except ksh88 and ksh93
> 
> - ksh88 does not honor backslashes inside a
>   character class. Since ksh93 changes this back to the
>   original Bourne Shell behavior, I would call it a bug.
> 
> - ksh93 interprets ["a-c"] different from all
>   other shells, but again interprets backshlash escapes
>   inside character classes.
> 
>   I remember that I received a report from someone (maybe
>   Martijn Dekker or Thorsten Glaser) that ksh93 has problems
>   with " inside some expressions.
> 
>   I would call the single deviation seen in ksh93 a bug.
>   The reason for this other behavior does not seem to be related
>   to pattern matching but to the way quote removal has been
>   implemented.
> 
> Conclusion:
> 
> Since the behavior of fnmatch() is currently not able to match the behavior
> of the shell matcher, I propose to add a new flag for fnmatch() to switch
> it into the shell mode that honors backslashes inside character sets.

You are conflating two different type of backslash escape.

The shell should honour backslash when used as shell quoting, regardless
of whether it is inside a bracket expression, but should not treat a
backslash in a bracket expression *that is part of the pattern* (i.e. not
shell quoting) as special.

For example:

[\"] the backslash quotes the "

["a\-c"] the backslash is not special and should be treated literally

If you want fnmatch() to be able to work like the shell you would need
the new flag to turn on all shell quoting (i.e. backslash, double-quotes
and single-quotes), not just backslash.

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

Re: Should shell quoting within glob bracket patterns be effective?

[Robert Elz]

Date:Thu, 12 Apr 2018 09:24:51 +0100
From:Geoff Clare 
Message-ID:  <20180412082451.GA3949@lt2.masqnet>

  | Bug 985 moves the detail from the current 2.13 into the fnmatch()
  | description and makes 2.13 refer to fnmatch().

Oh - I did not read all of it all that carefully - just the actual descriptions
of how it was to work.

I see no problem with that approach though -- that was what I intended
to say before I read the (old, TC2) fnmatch() page.

Both the shell, and the function, should act the same - if they don't the
function isn't nearly as useful.   Given that having the description in one,
and referring to it from the other seems appropriate, and I don't see that
it matters much which way it is done.

And yes, in particular if a [a\-c] means a class with the three chars 'a' '-'
and 'c' in it in sh it should mean that in fnmatch() as well, or if that 
pattern means a class with 8 chars (0x5c .. 0x63) with 'a' there 2 ways,
in fnmatch() then it should mean that in sh as well. 

On the other hand, having sh allow '' and "" quoting in addition to \ quoting
while not supporting that in fnmatch() is possible using a technique like
that in what was intended to be the 985 resolution - just provided that it
handles all of the cases correctly.

kre

Re: Should shell quoting within glob bracket patterns be effective?

[Joerg Schilling]

Robert Elz  wrote:

> Date:Wed, 11 Apr 2018 15:14:00 +0100
> From:Geoff Clare 
> Message-ID:  <20180411141400.GA32463@lt2.masqnet>
>
>   | I also have a feeling we will have to abandon the neat idea of defining
>   | shell pattern matching in terms of fnmatch(). 
>
> Yes, but for a slightly different reason - fnmatch() doesn't describe how
> the matching works, it just refers to XCU 2.13 for that info.   What it
> describes is a function that applications can call that does the same
> kind of matching as the shell does.
...

> Delete "quote removal" and in the description of how matching works, the
> quoting characters can be made to mean what they should mean for
> patterns - nothing needs to be "removed" here, as the pattern is just used
> for matching, the only result is matched or not matched.   Quoting just 
> affects
> the interpretation of the quoted characters, and otherwise matches nothing.

It seems that we need to define how quoting works in a real shell 
implementation. 

If we require the strings to be in the form \c\h\a\r in case of a quoted string 
at that specific part of the shell, we may explain how quoting works for "case"
statements.

Maybe, I should again mention history:

-   fmnatch() has been introduced with issue 4 (1995). It does not
seem to be related to a historic UNIX. Since the oldest known
implementation is from IBM, fnmatch() may have been introduced
by AIX.

-   The historic Bourne Shell used it's own implementation in 
expand.c:

case '[': 
{BOOL ok; INT lc; 
ok=0; lc=07; 
WHILE c = *p++ 
DO  IF c==']' 
THENreturn(ok?gmatch(s,p):0); 
ELIF c==MINUS 
THENIF lc<=scc ANDF scc<=(*p++) THEN ok++ FI 
ELSEIF scc==(lc=(c)) THEN ok++ FI 
FI 
OD 
return(0); 
} 

and this shows very obviously that [a\-c] is subject to quoting
as otherwise the code needs to read: ELIF (c)==MINUS
since the 1977 Bourne Shell did pass "[a\334c]" to the matching
function in expand.c if the command line was [a\-c].

-   A classical AT based UNIX in the late-1980s did have a 
library "libgen" with a function gmatch() inside that behaves 
like the code above, but by understanding "[a\-c]" instead of
"[a\334c]".

Now let us check the behavior of various shells with the following script:


mkdir td && cd td || exit

:> a
echo [a-c] ["a-c"] [\a\-\c] [a\-c]
rm a

:> b
echo [a-c] ["a-c"] [\a\-\c] [a\-c]
rm b

:> _
echo [a-c] ["a-c"] [\a\-\c] [a\-c]
rm _

:> \\ 
echo [a-c] ["a-c"] [\a\-\c] [a\-c] 
rm \\ 

:> d
echo [a-c] ["a-c"] [\a\-\c] [a\-c]
rm d

rm -f *
cd ..
rmdir td
---

This results in the following:

Bourne Shell:
a a a a
b [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]

ksh88:
a a a a
b [a-c] [a-c] b
[a-c] [a-c] [a-c] [a-c]
[a-c] \ \ \
[a-c] [a-c] [a-c] [a-c]

ksh93:
a a a a
b b [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]

bosh:
a a a a
b [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]

bash:
a a a a
b [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]

mksh:
a a a a
b [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]

dash:
a a a a
b [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]
[a-c] [a-c] [a-c] [a-c]

As we can see:

-   The Bourne Shell interprets backshlash escapes
inside character classes.

-   All other (relevant) shells behave identically
except ksh88 and ksh93

-   ksh88 does not honor backslashes inside a
character class. Since ksh93 changes this back to the
original Bourne Shell behavior, I would call it a bug.

-   ksh93 interprets ["a-c"] different from all
other shells, but again interprets backshlash escapes
inside character classes.

I remember that I received a report from someone (maybe
Martijn Dekker or Thorsten Glaser) that ksh93 has problems
with " inside some expressions.

I would call the single deviation seen in ksh93 a bug.
The reason for this other behavior does not seem to be related
to pattern matching but to the way quote removal has been
implemented.

Conclusion:

Since the behavior of fnmatch() is currently not able to match the behavior
of the shell matcher, I propose to add a new flag for fnmatch() to switch
it into the shell mode that honors backslashes inside character sets.

Re: Should shell quoting within glob bracket patterns be effective?

[Geoff Clare]

Robert Elz  wrote, on 12 Apr 2018:
>
> Date:Wed, 11 Apr 2018 15:14:00 +0100
> From:Geoff Clare 
> 
>   | I also have a feeling we will have to abandon the neat idea of defining
>   | shell pattern matching in terms of fnmatch(). 
> 
> Yes, but for a slightly different reason - fnmatch() doesn't describe how
> the matching works, it just refers to XCU 2.13 for that info.

Bug 985 moves the detail from the current 2.13 into the fnmatch()
description and makes 2.13 refer to fnmatch().

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

[1003.1(2013)/Issue7+TC1 0000985]: quote removal missing from case statement patterns and alternative expansions

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=985 
== 
Reported By:rhansen
Assigned To:
== 
Project:1003.1(2013)/Issue7+TC1
Issue ID:   985
Category:   Shell and Utilities
Type:   Omission
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   Richard hansen 
Organization:   BBN 
User Reference:  
Section:2.6.2, 2.9.4.3 
Page Number:2328, 2345 
Line Number:73944-73945, 74602-74603 
Interp Status:  Approved 
Final Accepted Text:http://austingroupbugs.net/view.php?id=985#c2885 
== 
Date Submitted: 2015-09-17 19:22 UTC
Last Modified:  2018-04-12 08:11 UTC
== 
Summary:quote removal missing from case statement patterns
and alternative expansions
==
Relationships   ID  Summary
--
related to  221 poor wording about even quotes in doubl...
related to  249 Add standard support for $'...' in shell
== 

-- 
 (0003948) geoffclare (manager) - 2018-04-12 08:11
 http://austingroupbugs.net/view.php?id=985#c3948 
-- 
On second thoughts, while the behaviour can't be specified in terms of an
fnmatch() call, perhaps it can still be done by reference to the fnmatch()
description.  Here's a suggested new version of 2.13 to replace the one in
http://austingroupbugs.net/view.php?id=985#c2885:

2.13 Pattern Matching Notation

The shell shall perform pattern matching as described for the
fnmatch() function (see [xref to XSH fnmatch()]) with the third
argument (flags) set to FNM_PATHNAME|FNM_PERIOD when the
pattern is being used for pathname expansion and 0 otherwise, except
that:If quote removal (see Section 2.6.7) has already been
performed on the pattern (as, for example, in a case compound
command), each character that was quoted by the quote characters that were
removed when quote removal was performed shall be treated as a literal
character.If quote removal has not yet been performed on the
pattern, the quote characters that will be removed when quote removal is
performed shall not be considered to be part of the pattern and each
character that is quoted by those quote characters shall be treated as a
literal character. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-09-17 19:22 rhansenNew Issue
2015-09-17 19:22 rhansenName  => Richard hansen  
2015-09-17 19:22 rhansenOrganization  => BBN 
2015-09-17 19:22 rhansenSection   => 2.6.2, 2.9.4.3  
2015-09-17 19:22 rhansenPage Number   => 2328, 2345  
2015-09-17 19:22 rhansenLine Number   => 73944-73945,
74602-74603
2015-09-17 19:22 rhansenInterp Status => --- 
2015-09-17 19:23 rhansenDesired Action Updated   
2015-09-17 19:24 rhansenDesired Action Updated   
2015-09-18 08:34 geoffclare Relationship added   related to 221  
2015-09-18 08:39 geoffclare Note Added: 0002835  
2015-09-18 20:08 shware_systems Note Added: 0002839  
2015-09-18 20:18 shware_systems Note Edited: 0002839 
2015-10-01 18:29 rhansenNote Added: 0002852  
2015-10-02 08:45 geoffclare Note Added: 0002853  
2015-10-02 17:13 rhansenNote Added: 0002855  
2015-10-03 00:57 shware_systems Note Added: 0002856  
2015-10-04 07:52 geoffclare Note Added: 0002858  
2015-10-08 16:14 rhansenNote Added: 0002863  
2015-10-08 16:31 rhansenNote Added: 0002864  
2015-10-08 16:40 geoffclare Note Added: 0002865  
2015-10-08 16:41 rhansenRelationship added   related to