On 2019/06/11 08:57, Joerg Schilling wrote:
> L A Walsh <[email protected]> wrote:
>
>> How will you tell if that is the case, or whether or not the
>> underlying OS hides (or provides) them, OR whether or not the
>> underlying file system supports them?
>>
>
> This is why the Bourne Shell supports set -o globskipdot since last weekend.
>
> The new code always hides the entries "." and ".." from readdir() and creates
> synthesized entries with "set +o globskipdot" (which is the default).
>
----
I think it is a very bad precedent for a shell to be synthesizing
non-existent path entries, period, let alone, by default.
Will some additional requirement be added that '..' open a uniq
parent on a relational-type file system where some concept-node might be
reached through different parent nodes even if the OS or file system
doesn't support it?
=======
On 2019/06/11 09:05, Joerg Schilling wrote:
> L A Walsh <[email protected]> wrote:
>
>
>> Writing code like that seems to be inviting undefined
>> behavior.
>>
>
> Correct, if we did _only_ change the POSIX standard to permit to hide "." and
> ".." from the glob results, this would cause undefined behavior.
>
> Even if we did require this behavior in Issue 9, this would still result in
> undefined behavior in 2030 since you cannot assume that at that time all
> platforms are Issue 9 compliant.
>
>
>
I think this may be rewording a similar point I was referring to. Anything
relying on ".." wouldn't know if it is running on a newer shell
shell that supports synthesis or an older shell that doesn't.
This raises another issue similar to what one would have on a
relational-type file system: It is already the case that ".." can have,
at least, three different meanings: the logical value due to symlinks, a
physical
value associated with a conventional file system AND similar to the symlink
case, the multi-answer value of '..' when you have the same subdirectory
mounted in multiple places.
There would be no way a shell could supply a 'correct answer' in such
situations.
Linda
