[Top][All Lists]

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

Re: Difference of extglob between 5.0.0(1)-release and 4.4.23(1)-release

From: Chet Ramey
Subject: Re: Difference of extglob between 5.0.0(1)-release and 4.4.23(1)-release
Date: Sat, 12 Jan 2019 20:58:04 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3

On 1/12/19 6:58 PM, Peng Yu wrote:
>> The bash-4.4 code only worked the way you want it by chance. There was a
> bug that was fixed in January, 2017, the result of
>> http://lists.gnu.org/archive/html/bug-bash/2017-01/msg00018.html
>> that uncovered the behavior you're complaining about.
> This only explains where the change of behavior for my example comes
> from. I assume that this is what you meant and you did not mean to use
> that email to justify the change for the example that I showed.

The key part of that paragraph is the first sentence. The explanation
of when it changed and why was for the off chance you might want to
investigate further yourself.

>> In a filename context, or a context where a leading `.' must be matched
>> explicitly, a pattern must only match a filename that starts with a `.' if
>> `.' is the first character in the pattern. A pattern that begins with a
>> null extglob pattern (especially one that is defined to perform at least
>> one match) followed by a dot, quoted or unquoted, does not fulfill that
>> criterion.
> I don't follow your explanation. Could you please use my specific
> examples and break it down into steps to show what globbing pattern
> matching is involved in bash5? And why the logic in bash4 was wrong?

Let's do it this way. I told you what the rule was. The pattern is "@().".
The filename is ".". Please explain why, according to the rule governing
matching files whose name begins with `.', that pattern should match.

> I don't think it is a good idea to introduce such kind of special
> cases. If @() should match an empty string, the least surprising
> definition is that it should match empty string everywhere. Weight the
> surprise that it could introduce, does the benefit of introducing
> special cases large enough to allow those special cases?

If you don't understand or remember the rule governing this behavior, it
might seem that it's introducing a special case. But the issue is not that
the pattern does match the empty string. It's because it appears where it
does in the pattern, even though it matches something successfully, so the
subsequent `.' is not the first character in the pattern, and fails the
rule, causing the pattern to not match.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://tiswww.cwru.edu/~chet/

reply via email to

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