Re: docs incorrectly mention pattern matching works like pathname expansion

[Stormy]

ok, I'm not that proficient with the inner workings.
I have a list of 'paths' as well as a list of 'patterns', and the bash script 
needs to decide if/what matches..
for example list of paths (these are highly simplified, real data can be 
anything under the sun):

/test/dir1/dir2/file2/test/dir1/dir4/file3/test/dir1/dir5/file4
list of patterns:
/test/dir?/dir?/file[a-z]/test/dir?/dir?/file*/test/dir*/test/dir?/dir?/file[0-9]
again, patterns can be anything.  The script needs to "predict" correctly which 
paths match which pattern.
I'm not fixated on 'case' or anything, but could not find a way to do it simply 
in bash.  folks suggest to do 'cd $path' but clearly that is not relevant in 
this case b/c these paths may not even exist on the system that runs this 
script :) :)

like I said, I've already implemented, roughly 40 lines in bash, and it seems 
to work, but if there is some builtin option 'shopt' or similar that can turn 
the right flags you mentioned, I'm all for testing it :)
Cheers.
Stormy.
 

    On Thursday, March 15, 2018, 9:17:47 PM GMT+2, Chet Ramey 
<chet.ramey@case.edu> wrote:  
 
 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/