Applications can be written portably and are expected to take into account a generic <i>file</i> operand is '.' or '..' already; readdir() may or may not include '.' or '..' values whenever a path crosses a device mount boundary. It may only have one or the other entries on the media to report; that is a file system design decision. As worded the implication is if only one is present, or none, that the other isn't to be synthesized as a separate dirent, or dirents, or merged with the one that is present as a dirent extension. The requirement on ls is that if either or both are present that they be listed when -a is specified, not that entries be synthesized, so readdir() can be used in ls. The file system used in the example appears to store both, so it looks like a requirement but isn't. I don't see anything normative that needs to be added. At most the Examples for various interfaces or utilities may need to be clearer on how these are expected to be processed, which is usually ignored. As an extension I can see adding GLOB_NODOTS as an option for the glob() interface, if an application wants to ensure no '.' or '..' entries are in the list returned by it, to get functionality equivalent to ls -A. In a message dated 6/7/2017 8:04:31 A.M. Eastern Daylight Time, [email protected] writes:
Stephane Chazelas <[email protected]> wrote: > So pdksh/zsh globs are currently only non-compliant in that they > may not match what readdir() returns, but in anycase, > applications cannot make much assumption on whether "." or ".." > should be returned, so that compliance issue is not very > relevant. Which is why it should do little harm to change the > spec to explicitely allow their behaviour. > > I even wonder if anyone would _object_ to POSIX *recommending* > (if not mandating) the pdksh/zsh behaviour. I would support to mandate this, but I fear that we could not rely on this behavior to be omnipresent for many years. Jörg -- EMail:[email protected] (home) Jörg Schilling D-13353 Berlin [email protected] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
