Date: Wed, 7 Jun 2017 13:00:27 +0100
From: Stephane Chazelas <stephane.chaze...@gmail.com>
Message-ID: <20170607120027.gd5...@chaz.gmail.com>
| I even wonder if anyone would _object_ to POSIX *recommending*
| (if not mandating) the pdksh/zsh behaviour.
I think I would, I am not generally in favour of software attempting to
second guess what it thinks the user "almost always wants". The current
rule is simple, if a component pattern starts with a "." then file names
(which match the rest of the pattern) are included in the result. Not
just some of them.
But I certainly don't object to making it clear that some systems don't
really have a "." or ".." in the directory, and so those don't exist to be
matched, and so won't be returned.
Of course, I still miss the days when I could (and quite frequently did)
rearrange the directory entries so (rarely, but I have done it) "." is not
a reference to self, and (more frequently) ".." is not a reference to "the"
parent (and as allowing multiple entries to link to the same directory was
possible, there wasn't necessarily a "the" parent to refer to in any case,)
And while here, I am also not in favour of attempts to "fix" breakage, just
so we appear to conform to the standard. If "." and ".." are supposed to
appear in the directories, and (for whatever reason) only one of them happens
to be there, then readdir() should return just that one, not attempt to
fake the other one. It would be different on a system that actually
implemented ".." in the directory, but omitted "." so this was a normal
state, in that case, having readdir() either suppress the ".." entry or add
a generated "." entry would be reasonable.
kre
