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

[Stephane Chazelas <stephane@xxxxxxxxxxxx>]

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. 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.

What should the outcome be for ESYS123 error code?

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

> > [...]
> > >   -e  pathname
> > >     True if pathname resolves to an existing directory entry.
> > >     False if pathname cannot be resolved.
> > > 
> > > BTW, I don't know how zsh behaves on "[[ -e pathname ]]" in case of
> > > error other than ENOENT in the pathname resolution, but this should
> > > be documented (and ditto for the other conditional expressions).
> > [...]
> > 
> > The mention of "directory entry" is misleading here. It's really
> > about a "file" more than a "directory entry" as stat() gets you
> > to the inode.
> 
> Bart replied. In any case, the inode here will necessarily correspond
> to a directory entry (it will not be an orphaned inode), and with the
> symlink resolution algorithm, you can also determine the directory in
> question. So, nothing wrong here.
[...]

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.

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).

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

-- 
Stephane