Re: glob qualifier '-' doesn't work correctly on dangling symlinks

[Vincent Lefevre <vincent@xxxxxxxxxx>]

On 2020-04-14 07:18:16 +0100, Stephane Chazelas wrote:
> 2020-04-13 23:41:49 +0200, Vincent Lefevre:
> [...]
> > > Which one(s) should find -L . -type l (or find . -xtype l)
> > > print?
> > 
> > /etc/passwd/foo
> > /etc/pesswd/foo
> > symloop/foo
> > 
> > (and I would expect an error message for /root/foo, such as
> > "Permission denied", in addition to a non-zero exit status).
> 
> So not that "unambiguous" after all.

Note that "unambiguous" does not necessarily mean that the
result is known.

> I could not find a single
> find implementation that agrees with your interpretation (not
> that it means that your intepretation is better or worse).
> 
> GNU find for instance only prints /etc/pesswd/foo and
> /etc/passwd/foo (but outputs an error for the latter) and
> returns non-zero for anything but /etc/pesswd/foo.

I've said that for ELOOP (here, symloop/foo), it should be fine to
regard this as "not an error". This does not mean that the opposite
is necessarily wrong. IMHO, this is just a bad choice.

IMHO, the fact that it returns non-zero for /etc/passwd/foo is a
bug.

> What should the outcome be for ESYS123 error code?

It seems non-standard, thus an error (unless the implementation
knows what it means and the consequence on the existence of the
file).

Note that in any case, an error is always possible, even when not
expected. For instance, it could be due to a network issue in case
of NFS, and more generally some hardware failure. Script must be
able to handle errors at any time.

> To me, the best approach is zsh's where *(-@) reports *all*
> broken links, broken meaning "whose target cannot be resolved".

Since zsh regards "permission denied" errors as non-matching (for
instance, on my machine, /r*/* expands to objects under /run, with
no errors, even though the /root directory is not accessible),
I think it is fine that here, EACCES errors (permission denied) be
regarded as non-existing. But IMHO, "serious" errors such as ENOMEM
should be reported as such with globbing (in general, not just for
symlink resolution), i.e. zsh should not execute the command and
should report an error instead, like with a "bad pattern" error.

[...]
> An example:
> 
> # ls -la
> total 1
> drwxr-xr-x 2 root root 2 Aug 15  2018 ./
> drwxr-xr-x 5 root root 5 Mar 18  2019 ../
> # [[ -e .zfs ]] && echo yes
> yes
> 
> No .zfs directory entry, but [[ -e .zfs ]] still returns true.
> On ZFS filesystems, the root of each dataset has a hidden
> "virtual" .zfs directory that "exists" but not as a directory
> entry. That's not unique to ZFS, netapp FSs and several
> fuse-based ones are in that case.

Is this POSIX compliant? If it is, I would say that it is a bug.

> And there's:
> 
> $ ls -a 1
> .  ..  file
> $ ls -ld 1
> dr--r--r-- 2 chazelas chazelas 3 Apr 14 07:07 1
> $ [[ -e 1/file ]] || echo no
> no
> $ (){(($#))} (#I)1/file(|)(N) && echo yes
> yes
> 
> That directory does have a "file" entry but [[ -e 1/file ]] does
> not report it (and there's a symmetric problem for a=x
> directories which don't have entries which the user can see but
> for which [[ -e ... ]] finds entries).

I would say that this is a also a bug. However, perhaps not since
how the resolution is done is not specified.

> There's also the case of case insensitive or unicode-normalizing
> file systems.

POSIX compliant?

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)