Re: docs incorrectly mention pattern matching works like pathname expansion

[Chet Ramey]

On 3/15/18 12:15 PM, Stormy wrote:
> Thanks for the reply.  I'm not sure we are talking about the same thing.. 
> maybe..does this example help?
> # case /test/test2/dir1/file in  /test/*) echo 'match';; *) echo 'nomatch';; 
> esac
> match
> 
> here, the expectation is to NOT match, since '/test/*' in normal shell, i.e. 
> "ls", would NOT match that long path.  by path name expansion, man page is 
> hinting it behaves like "ls", but clearly it does not.

No, we're talking about the same thing.

There is a behavior difference between pathname and non-pathname matching
contexts: when matching a pathname, a slash in the pathname has to be
matched by a slash in the pattern.

The text I quoted, which appears in the "Pathname Expansion" section of
the man page (referenced in the description of `case') says exactly that.

What it doesn't say is the converse: that when not matching a pathname,
the slash doesn't need to be matched explicitly. The second part of my
comment proposes adding text to say that.

What I'll probably end up doing is to change some places to refer directly
to pattern matching instead of referring to pathname expansion and letting
that section refer to pattern matching.

> in summary, it seems bash has no internal fnmatch(3) implementation.

Nothing you've said implies that. In fact, the opposite is true.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/