Re: docs incorrectly mention pattern matching works like pathname expansion

[PePa]

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.ramey@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.
> 
>