From: Stephane Chazelas <stephane@chazelas.org>
To: zsh-workers@zsh.org
Subject: Re: glob qualifier '-' doesn't work correctly on dangling symlinks
Date: Tue, 14 Apr 2020 07:18:16 +0100 [thread overview]
Message-ID: <20200414061816.5qfbjyc6w3x34wcz@chazelas.org> (raw)
In-Reply-To: <20200413214149.GA2644627@zira.vinc17.org>
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
next prev parent reply other threads:[~2020-04-14 6:19 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
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 [this message]
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=20200414061816.5qfbjyc6w3x34wcz@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).