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

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Stephane Chazelas wrote on Tue, 14 Apr 2020 07:18 +0100:
> 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".

Counter-argument: since an ENOMEM during symlink resolution causes
«(-@)» to presume the symlink is broken, the zsh language is
non-deterministic: what «intact-symlink(N-@)» will expand to will
depend on whether there is enough memory at runtime.

Shouldn't an ENOMEM during expansion of «intact-symlink(N-@)» result in
an error?  "In the face of ambiguity, refuse the temptation to guess."

That is: I think there's a qualitative difference between ENOENT and ENOMEM.

I'm not sure what to do about unknown error codes.

Cheers,

Daniel