Re: docs incorrectly mention pattern matching works like pathname expansion

[Chet Ramey]

On 3/15/18 2:50 PM, Stormy wrote:
> Chet,
> 
> ok, replacing 'pathname expansion' with 'pattern matching' is the right
> solution, otherwise u end up with a lot of confusing explanations :)
> 
> if u think bash has builtin 'fnmatch' functionality, do u have an example
> clearly we see that 'case' above is not doing it.  Similarily, [[ "$text"
> == $pattern ]]  does not (also =~ is not relevant since pathname is not
> pure regex).. These all do pattern matching, but not PATH NAME matching (as
> what "ls" would do)..  I'm not sure what I said to make it sound like bash
> does have it.. 

I think you're confusing fnmatch with the FNM_PATHNAME option and fnmatch's
default behavior. When fnmatch is used to match a pathname, you pass the
FNM_PATHNAME flag to get the special behavior for slash (and, if desired,
the FNM_PERIOD flag to get the behavior of matching a leading `.'
explicitly).

The instances (case, [[, the pattern replacement and removal word
expansions) where bash's fnmatch equivalent isn't matching a pathname are
where it doesn't pass the FNM_PATHNAME or FNM_PERIOD options.

> Sure, one can use "ls" to expand a path, but what if it does not exist or u
> just want to match paths directly in bash?

What is it you want to do? Turn the equivalent of the FNM_PATHNAME flag
on when running `case'? That's not how `case' works.

If you want to expand filenames or match filenames using a pattern, you'll
have to use the patterns in a context where filename expansion is
performed. The man page is pretty good about listing those cases (e.g., the
arguments to a simple command).

-- 
``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/