Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: glob qualifier '-' doesn't work correctly on dangling symlinks
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author