Zsh Mailing List Archive
Messages sorted by:
Re: glob qualifier '-' doesn't work correctly on dangling symlinks
On 2020-04-12 08:09:30 +0100, Stephane Chazelas wrote:
> 2020-04-12 04:17:22 +0200, Vincent Lefevre:
> > zira% ln -s /does-not-exist s1
> > zira% ln -s /root/foo s2
> > zira% ls -L s*
> > ls: cannot access 's1': No such file or directory
> > ls: cannot access 's2': Permission denied
> > But with glob qualifiers, there does not seem to be a way to
> > distinguish these two cases.
> $ zmodload zsh/system
> $ ls -ld -- *(e[ERRNO=0]-e['[[ $errnos[ERRNO] = EACCES ]]'])
> lrwxrwxrwx 1 chazelas chazelas 9 Apr 12 07:34 s2 -> /root/foo
> $ ls -ld -- *(e[ERRNO=0]-e['[[ $errnos[ERRNO] = ENOENT ]]'])
> lrwxrwxrwx 1 chazelas chazelas 15 Apr 12 07:34 s1 -> /does-not-exist
> (the ERRNO=0 may not be necessary).
Well, I implicitly meant with simple glob qualifiers. Otherwise,
when allowing 'e' (to run arbitrary code), one can do almost
anything based on available information.
> $ find -L . -perm -o=w
> find: ‘./s2’: Permission denied
> But again, *(-@) for broken symlinks is documented and widely
> used, we can't break that.
But widely used for what purpose exactly?
For instance, if the goal is to list dangling symlinks only, then
"permission denied" cases (EACCES) would yield false positives, and
existing code may be broken. So, perhaps '-' should still be kept
for dangling symlinks, but its behavior might need to be changed to
match the currently expected behavior.
And what about less common errors such as ENOMEM?
> So if we change "-" to exclude broken symlinks, we'd need to
> special case -@. What's the scope of what should be special
> cased? *(-@e['((count++))']) should probably still work as well
> for instance.
> How about: *(-e['((n++))']@['((brokenlinks++))'])?
> And *(-@m-1) (broken links created in the last 24 hours, though
> I'd expect one to write *(m-1-@) instead here)
> Note that for "find -L", zsh's current behaviour is required by
> POSIX (at least for links whose target can be determined not to
> Cause the file information and file type evaluated for
> each symbolic link encountered as a path operand on
> the command line or encountered during the traversal
> of a file hierarchy to be those of the file referenced
> by the link, and not the link itself. If the
> referenced file does not exist, the file information
> and type shall be for the link itself.
At least, that's explicit, unambiguous documentation.
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)
Messages sorted by: