David A. Wheeler wrote, on 10 Aug 2023: > > > On Aug 10, 2023, at 11:11 AM, Austin Group Bug Tracker via austin-group-l > > at The Open Group <austin-group-l@opengroup.org> wrote: > > > > User Reference: > > https://www.mail-archive.com/austin-group-l@opengroup.org/msg01176.html > > Section: Pathname Expansion > > Page Number: 2384 > > Line Number: 76271 > > Interp Status: --- > > Final Accepted Text: > > https://austingroupbugs.net/view.php?id=1228#c5889 > > I'm all for this change, in fact, requiring systems to *not* include . and .. > as glob results (someday) would be great. > > However, could this be misinterpreted as allowing a tool to respond to > "./*.pdf" as *removing* the "./" when returning a match?
The handling of the "./" part of "./*.pdf" is governed by the pathname resolution rules. They require the "." to resolve to the current working directory regardless of whether a directory entry for "." exists. In other words, "." in a pathname is a special pathname component, it is not a reference to a directory entry. Since the wording in the 1228 resolution talks about directory entries, it has no effect on the initial "."; it only affects how the "*.pdf" part is matched against the directory entries read from the current working directory. Even if someone did try to misinterpret the text as allowing the initial "." to be ignored, the end result of an expansion with it ignored would be a set of pathnames that each begin with "/". That is so obviously not intended, it would be a big clue that they have misinterpreted the text. -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
