> 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
