bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: docs incorrectly mention pattern matching works like pathname expans


From: PePa
Subject: Re: docs incorrectly mention pattern matching works like pathname expansion
Date: Thu, 15 Mar 2018 23:32:36 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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 
> <address@hidden> 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.
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]