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 c...@case.edu http://tiswww.cwru.edu/~chet/
