Geoff Clare <> wrote:

> Clearly the statement in XBD 9.3.5:
>     The special characters '.', '*', '[', and '\\' ( <period>,
>     <asterisk>, <left-square-bracket>, and <backslash>, respectively)
>     shall lose their special meaning within a bracket expression.
> is intended to apply to backslashes in fnmatch(), just as it does to
> the special meaning of backslash stated in XCU 2.13.1 (which also
> doesn't mention an exception for bracket expressions).

It seems that everybody agrees that [a-z] should behave different to ["a-z"].
How this is implemented in the shell is not mentioned in POSIX. It seems 
however that people tend to use a prepended '\\' in strings to mark quoted 
characters in shell internal strings.

> The whole point of adding fnmatch() to the standard was to provide a
> a function which implements XCU 2.13, so any interpretation of the
> standard which has backslash being treated differently in fnmatch()
> (without FNM_NOESCAPE) than in XCU 2.13 cannot be correct.

If the intention was not to add a new interface but to add an interface that 
could be used to give the same results as seen in the shell, then I would 
expect fnmatch() to honor backslashes in [..] constructs as long as 
FNM_NOESCAPE is not in effect.

> While quoting it here, I just noticed that this statement also has
> another issue when being read in the context of XCU 2.13.1: it should
> refer to '?' losing its special meaning instead of '.'.  I'll update
> my proposed change in bug 1190 to address that.

It may be that the original intention was not to enforce people to implement 
shell internal quoting by using prepended '\\' characters in the strings that 
are used internally after tokenization in the parser. In case that a different 
mechanism is used, it would need a different implementation in fnmatch() as 

I am not aware of a shell implementation that today uses a different method, so 
implementing backslash based quoting in fnmatch() seems to be the obvious 
method to recreate the behavior of the shell.


--                    (home) Jörg Schilling D-13353 Berlin (work) Blog:

Reply via email to