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
