From: Stephane Chazelas <stephane@chazelas.org>
To: zsh-workers@zsh.org
Subject: Re: glob qualifier '-' doesn't work correctly on dangling symlinks
Date: Sun, 12 Apr 2020 08:09:30 +0100 [thread overview]
Message-ID: <20200412070930.etfzj6j2qvd5em7b@chazelas.org> (raw)
In-Reply-To: <20200412021722.GA1748686@zira.vinc17.org>
2020-04-12 04:17:22 +0200, Vincent Lefevre:
[...]
> > What would be the glob qualifier syntax for broken symlinks?
>
> There would need something for that. But even currently, there
> are things one cannot do with glob qualifiers, such as one does
> not have a way to know the reason why a symlink is broken, which
> can be important when one is interested in broken symlinks.
>
> 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.
[...]
There's:
$ 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).
Note:
$ find -L . -perm -o=w
./s1
find: ‘./s2’: Permission denied
But again, *(-@) for broken symlinks is documented and widely
used, we can't break that.
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
exist):
-L
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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I find some variation in behaviour though:
$ ln -s /etc/passwd/foo s3
$ gfind . -follow -perm -o=w
gfind: ‘./s3’: Not a directory
./s3
./s1
gfind: ‘./s2’: Permission denied
$ busybox find . -follow -perm -o=w
find: ./s3: Not a directory
./s1
find: ./s2: Permission denied
$ find_su3 . -follow -perm -o=w
find_su3: cannot follow symbolic link ./s3: Not a directory
find_su3: cannot follow symbolic link ./s1: No such file or directory
find_su3: cannot follow symbolic link ./s2: Permission denied
(the latter from the heirloom toolchest being not POSIX compliant)
In any case, in */*(W), or ***/*(W) or **/*(W), the cases where
directories are not readable or searchable, or symlink targets
not accessible are always silently ignored (as opposed to the
find equivalents).
--
Stephane
next prev parent reply other threads:[~2020-04-12 7:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-11 15:15 Vincent Lefevre
2020-04-11 17:34 ` Stephane Chazelas
2020-04-11 19:17 ` Vincent Lefevre
2020-04-11 20:37 ` Stephane Chazelas
2020-04-11 23:48 ` Vincent Lefevre
2020-04-12 1:21 ` Daniel Shahaf
2020-04-12 2:17 ` Vincent Lefevre
2020-04-12 7:09 ` Stephane Chazelas [this message]
2020-04-12 14:25 ` Vincent Lefevre
2020-04-12 17:34 ` Stephane Chazelas
2020-04-12 23:38 ` Vincent Lefevre
2020-04-13 14:22 ` Stephane Chazelas
2020-04-13 15:00 ` Bart Schaefer
2020-04-13 21:41 ` Vincent Lefevre
2020-04-14 6:18 ` Stephane Chazelas
2020-04-14 12:02 ` Daniel Shahaf
2020-04-14 12:38 ` Stephane Chazelas
2020-04-15 0:44 ` Daniel Shahaf
2020-04-15 9:17 ` Vincent Lefevre
2020-04-14 17:59 ` Vincent Lefevre
2020-04-12 12:48 ` Peter Stephenson
2020-04-12 14:31 ` Vincent Lefevre
2020-04-12 15:49 ` Peter Stephenson
2020-04-12 23:07 ` Vincent Lefevre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200412070930.etfzj6j2qvd5em7b@chazelas.org \
--to=stephane@chazelas.org \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).