Re: docs incorrectly mention pattern matching works like pathname expansion

[Stormy]

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..  
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?

I ended up writing ~40 lines of code that implement fnmatch directly in bash, 
hence ran into this doc issue.
you can also search online 'fnmatch' bash, and see, folks cannot figure it out 
:)
anyways, I'm not complaining or anything, just thought it would be a good idea 
to bring to your attention, frankly I'm pleasantly surprised with the swift 
attention and replies.
Good luck.Stormy.
 

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