Re: Difference of extglob between 5.0.0(1)-release and 4.4.23(1)-release
On 1/13/19 8:45 AM, Ilkka Virta wrote: > On 13.1. 14:37, Andreas Schwab wrote: >> On Jan 13 2019, Robert Elz wrote: >> >>> The pattern >>> ./$null"$dir"/ >>> >>> is expanded (parameter expansion) to >>> >>> ./@()./ >>> >>> which does not have a "." immediately after the / and >>> tus cannot match any filename (incoludeing ".") which >>> starts with a '.' character. >> >> For the same reason `*.' doesn't match `.'. Making `@()' work differently >> from `*' would be surprising. > > However, ?(aa).foo matches the file .foo in Bash 4.4 and 5.0 (and also > in Ksh and Zsh), so extglob already breaks the above mentioned rule. Yes. That was part of the overhaul of this code that I referred to in my first reply. I found that in ksh93 the extglob operators *(...) and ?(...) will match the leading dot, so I implemented it that way for compatibility. > The change in Bash 5.0 also makes @(aa|) different from ?(aa) , even > though the distinction between those two doesn't appear immediately obvious. My guess is the difference between those two operators in ksh93 is that the @ has to match one of the patterns where the ? can match 0 occurrences. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Difference of extglob between 5.0.0(1)-release and 4.4.23(1)-release
On 13.1. 14:37, Andreas Schwab wrote: On Jan 13 2019, Robert Elz wrote: The pattern ./$null"$dir"/ is expanded (parameter expansion) to ./@()./ which does not have a "." immediately after the / and tus cannot match any filename (incoludeing ".") which starts with a '.' character. For the same reason `*.' doesn't match `.'. Making `@()' work differently from `*' would be surprising. However, ?(aa).foo matches the file .foo in Bash 4.4 and 5.0 (and also in Ksh and Zsh), so extglob already breaks the above mentioned rule. $ touch .foo aa.foo; bash -O extglob -c 'echo ?(aa).foo' aa.foo .foo The change in Bash 5.0 also makes @(aa|) different from ?(aa) , even though the distinction between those two doesn't appear immediately obvious. -- Ilkka Virta / itvi...@iki.fi
Re: Difference of extglob between 5.0.0(1)-release and 4.4.23(1)-release
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. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Difference of extglob between 5.0.0(1)-release and 4.4.23(1)-release
Date:Sat, 12 Jan 2019 17:58:12 -0600 From:Peng Yu Message-ID: | 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. Yes, and it does I think. That isn't the issue. The issue is that (for historical reasons) a '.' that starts a filename has special matching rules, and can only be matched by an explicit '.' in the pattern and only whet that '.' is either the first character in the pattern, or immediately after a '/' - in no other cases does a filename starting with a '.' (where by filename here, I mean the entry in any directory) ever match a glob pattern. In yoru exmaple... The pattern ./$null"$dir"/ is expanded (parameter expansion) to ./@()./ which does not have a "." immediately after the / and tus cannot match any filename (incoludeing ".") which starts with a '.' character. The leading '.' in that pattern "./" is fine and will match the current directory "." (well, there are no patterns, so no matching, it just is the cirrent directory). | Weight the surprise that it could introduce, does the benefit | of introducing special cases large enough to allow those | special cases? The surprise would be if this ever did work, as the way leading filename '.' chartacters work as been in unix glob handling for more than 40 years. It means that when you say "*" you don't get "." or any other files that start with "." included (etc). And the rule has always beenvery simple. You want '.' you write '.' (even writing it as [.] which, given '.' is not special in glob patterns woudl mean the exact same thing for any other character, is not defined to work for this, and can result in nothing possibly matching (this is an unspecified case.) You need to learn the rules. kre ps; there is a very good chance that this message will not get to Peng Yu ... gmail and munnari dislike each other (well, gmail dislikes munnari, munnari is pretty tolerant and keep trying anyway...) that is unless he is on the list and gets the message that way.
Re: Difference of extglob between 5.0.0(1)-release and 4.4.23(1)-release
> 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. > 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? > I wouldn't be so quick to declare this a bug. Other shells (e.g, ksh93, > mksh, and zsh) that implement extended globbing patterns behave like > bash-5.0 does. > > There is a question of whether or not an extglob pattern that is allowed > to make zero matches followed by a `.' should succeed, and the existing > implementations are mixed on that point. 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? -- Regards, Peng
Re: Difference of extglob between 5.0.0(1)-release and 4.4.23(1)-release
On 1/12/19 12:17 AM, Peng Yu wrote: > See the following for the difference. I'd consider the behavior of > 4.4.23 should be correct. 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. I am not sure of your characterization of the bash-4.4 behavior as correct. 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. > > How was this bug introduced? Should there be a test case to cover this case? I wouldn't be so quick to declare this a bug. Other shells (e.g, ksh93, mksh, and zsh) that implement extended globbing patterns behave like bash-5.0 does. There is a question of whether or not an extglob pattern that is allowed to make zero matches followed by a `.' should succeed, and the existing implementations are mixed on that point. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
