It is clear that the matching in 'case' does general pattern matching but not pathname matching. I think the bash man page should say so, clearly distinguishing different ways of matching in bash.
Peter On 03/15/2018 11: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. > in summary, it seems bash has no internal fnmatch(3) implementation. > > > On Thursday, March 15, 2018, 5:26:32 PM GMT+2, Chet Ramey > <chet.ra...@case.edu> wrote: > > On 3/14/18 1:43 PM, Stormy wrote: > >> Bash Version: 4.2 >> Patch Level: 46 >> Release Status: release >> >> Description: >> Section of 'case' in bash's man page says: >> >> case word in [ [(] pattern [ | pattern ] ... ) list ;; ] ... esac >> A case command first expands word, and tries to match it >> against each pattern in turn, using the same matching >> rules as for pathname expansion (see Pathname Expansion below). >> >> but that is not correct, the matching here does NOT follow pathname >> expansion, the treatment of "/" is not the same. > > The description of Pathname Expansion says, in part: > > "When matching a > pathname, the slash character must always be matched explicitly." > > but I can expand that to also say that it other contexts it does not need > to be. > >