Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001295 [1003.1(2016)/Issue7+TC2] Shell and Utilities Comment Omission 2019-10-02 21:17 2019-12-12 17:17
Reporter hvd View Status public  
Assigned To
Priority normal Resolution Rejected  
Status Closed  
Name Harald van Dijk
Organization
User Reference
Section 2.13
Page Number 2383
Line Number 76231
Interp Status ---
Final Accepted Text
Summary 0001295: Left brackets in shell patterns may cause other pattern matching characters to be taken literally in all contexts
Description 2.13.3 "Patterns Used for Filename Expansion" states that for patterns that contain an open bracket that does not introduce a bracket expression, it is unspecified whether other unquoted pattern matching characters retain their special meanings. However, existing shell behaviour is that in shells where they do not retain their special meanings, this is not affected by whether the pattern is used for filename expansion, the characters do not retain their special meaning in other contexts either, the shells treat those characters as literal in case statements and parameter expansions involving #/##/%/%% too. The specification for this for patterns not used for filename expansion is missing.
Desired Action In 2.13.1 "Patterns Matching a Single Character", change

Otherwise, '[' shall match the character itself.

to

Otherwise, '[' shall match the character itself, and for patterns not used for filename expansion, it is unspecified whether other unquoted pattern matching characters within the same pattern retain their special meanings or are treated as ordinary characters. For example, the pattern "a*[" may match the literal string "a*[", or it may all strings beginning with 'a' and ending with '['. For patterns used for filename expansion, see 2.13.3.

(The proposed resolution for bug 1234 changes 2.13.3's "pattern matching characters" to "'*', '?', '[' or <backslash> characters". If that change is applied, the same change should be made in the desired action here.)
Tags No tags attached.
Attached Files

- Relationships
child of 0001234Applied in most shells, backslash doesn't have two meaning wrt pattern matching 

-  Notes
(0004628)
shware_systems (reporter)
2019-10-28 18:09

I don't see the requirements as having been ambiguous... if '[' is an ordinary character, due to escape quoting or lack of closing ']', like with other ordinary characters '*' and '?' are pattern special and match accordingly. It is when a closing unquoted ']' is present (before any '/' a pathname pattern may have) that the opening '[' might force '*' and '?' to be non-special, e.g. [*-?] treating them as ordinary for a range specification, even without being escape quoted. An implementation that treats a '*' in an a*[ token body, or interface argument string, as an ordinary character is simply buggy therefore, not conforming.
(0004629)
hvd (reporter)
2019-10-28 19:13

2.13.3 is already clear that treating the "*" in "a*[" as a literal character is meant to be allowed, and several shells do that. The only problem this bug is about is that 2.13.3 does not cover all patterns; this bug is about copying 2.13.3's wording for the patterns not covered by 2.13.3.
(0004630)
stephane (reporter)
2019-10-28 20:30

> it is unspecified whether other unquoted pattern matching characters
> within the same pattern retain their special meanings or are treated as
> ordinary characters. For example, the pattern "a*[" may match the literal
> string "a*[", or it may all strings beginning with 'a' and ending with '['.

The only shells that I know that do anything like that are the Bourne shell and its descendants like ksh88, ksh93 and bosh (when the posix option is not enabled), where patterns match themselves, as in

   case "[a]" in [a]) echo yes; esac

outputting "yes".

POSIX has already clarified that it was not an acceptable behaviour.

Once that behaviour is fixed in those non-conforming implementations (like in bosh -o posix), I don't expect there would be any where

case xy*[ in
  x*[) echo 1;;
  xy*[) echo 2;;
esac

would output 2, so I don't think it's a good idea to suggest that some might.

Here, the most sensible behaviour IMO would be zsh's ones that complains about an invalid pattern upon unmatched "[" (except for the special case of "[" alone for the alias to the test command) but unfortunately IIRC, it's currently not allowed by POSIX.
(0004631)
hvd (reporter)
2019-10-28 21:10

> Once that behaviour is fixed in those non-conforming implementations (like in bosh -o posix), I don't expect there would be any where

> case xy*[ in
> x*[) echo 1;;
> xy*[) echo 2;;
> esac

> would output 2, so I don't think it's a good idea to suggest that some might.

pdksh/posh, which do not have the problem you mention, already do output 2 for this.
(0004632)
stephane (reporter)
2019-10-29 07:56

Re: Note: 0004631
> pdksh/posh, which do not have the problem you mention, already do output 2 for this

You're right. I was finding that behaviour so surprising I didn't imagine it could be explained by anything else, my bad for not double-checking.

Looking at the pdksh code, its has_globbing() returns "false" if the pattern is invalid (in this case, if there's an unmatched "["), and in that case, it does a byte-to-byte comparison.

That changed in mksh in 2017, https://github.com/MirBSD/mksh/commit/f2de19c4 [^]
(0004684)
geoffclare (manager)
2019-12-12 17:17

This was discussed in the 2019-12-12 teleconference. Since the only shells that would need this change are pdksh and posh, neither of which aims to be fully POSIX conforming, this bug is being rejected.

- Issue History
Date Modified Username Field Change
2019-10-02 21:17 hvd New Issue
2019-10-02 21:17 hvd Name => Harald van Dijk
2019-10-02 21:17 hvd Section => 2.13
2019-10-02 21:17 hvd Page Number => -
2019-10-02 21:17 hvd Line Number => -
2019-10-02 21:45 Don Cragun Relationship added child of 0001234
2019-10-02 21:49 Don Cragun Page Number - => 2383
2019-10-02 21:49 Don Cragun Line Number - => 76231
2019-10-02 21:49 Don Cragun Interp Status => ---
2019-10-28 18:09 shware_systems Note Added: 0004628
2019-10-28 19:13 hvd Note Added: 0004629
2019-10-28 20:30 stephane Note Added: 0004630
2019-10-28 21:10 hvd Note Added: 0004631
2019-10-29 07:56 stephane Note Added: 0004632
2019-12-12 17:17 geoffclare Note Added: 0004684
2019-12-12 17:17 geoffclare Status New => Closed
2019-12-12 17:17 geoffclare Resolution Open => Rejected


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