On 6/5/21 8:42 PM, Nora Platiel wrote:
The "matched explicitly" refers to the previous sentence, which talks about
the `.' at the start of a filename or path component needing to be matched
explicitly by a pattern beginning with a `.' or containing a `.' at the
right spot (after a `/'). I can add language to clarify that.
What about this?
The character `.' at the start of the
| filenames `.' and `..' must always be matched explicitly, even if dotglob
| is set.
I added something similar, with additional wording about a `.' at the start
of a pattern.
Yes, it all depends on the "universal set" from which the matches of the inner
`pattern-list' are subtracted.
But in the current implementation, the inner matches are subtracted from:
- all files, if dotglob is set
- all except dot files, if dotglob is unset
The inclusion of `.' and `..' when dotglob is set, seems inconsistent with the
exclusion of dot files when dotglob is unset.
I think it would be most intuitive and useful to define the universal set to be
whatever `*' can expand to.
I can see how this would be more intuitive. Let's try it. I'll put support
in the next devel branch push.
About the behavior of the extended operators ?,*,+,@ (with my proposed changes
when dotglob is set), I'm not sure there's a need for explanation. I think it
comes natural if you mentally translate the extended pattern into a sequence of
non-extended patterns.
About `!()', we could say:
I'm leaning towards a general statement about how dotglob affects the set
of filenames that are tested against the extended patterns, rather than
calling out `!' specially.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
