View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001295 | 1003.1(2016/18)/Issue7+TC2 | Shell and Utilities | public | 2019-10-02 21:17 | 2019-12-12 17:17 |
| Reporter | hvd | Assigned To | |||
| Priority | normal | Severity | Comment | Type | Omission |
| Status | Closed | Resolution | Rejected | ||
| 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
to
(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. | ||||
| child of | 0001234 | Closed | in most shells, backslash doesn't have two meaning wrt pattern matching |
|
|
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. |
|
|
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. |
|
|
> 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. |
|
|
> 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. |
|
|
Re: 0001295: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 |
|
|
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. |
| 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 |
