2017-06-07 12:24:33 +0100, Geoff Clare: [...] > > Yes, it's hard to tell what behaviour one can rely on with the > > current text. Is opendir(".") required to open the current > > directory even if there's no "." entry in the current directory > > (same for "..")? Is foo/./bar required to be the same as > > foo/bar? > > The answer to both of those question is yes. See XBD 4.13 Pathname > Resolution. [...]
Thanks again. I overlooked that as I was skimming over it and searching for "."/".." when I should have been looking for "dot" or "dot-dot" instead. Sorry for the noise. So, "." and ".." should be recognised in pathnames (except for /.. which is undefined and non-directory-nor-symlink-to-directory/.. which should be an error) regardless of whether corresponding entries "exist" in the correspond directories, while readdir() may or may not list them, but if they list one (either "." or ".."), they should list the other as well (and I suppose it's the intention for "ls -a" as well). 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. -- Stephane