From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 22889 invoked from network); 14 Apr 2020 06:19:11 -0000 Received-SPF: pass (primenet.com.au: domain of zsh.org designates 203.24.36.2 as permitted sender) receiver=inbox.vuxu.org; client-ip=203.24.36.2 envelope-from= Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with UTF8ESMTPZ; 14 Apr 2020 06:19:11 -0000 Received: (qmail 14192 invoked by alias); 14 Apr 2020 06:19:00 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45692 Received: (qmail 28021 invoked by uid 1010); 14 Apr 2020 06:19:00 -0000 X-Qmail-Scanner-Diagnostics: from relay11.mail.gandi.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.2/25779. spamassassin: 3.4.4. Clear:RC:0(217.70.178.231):SA:0(-2.6/5.0):. Processed in 3.555566 secs); 14 Apr 2020 06:19:00 -0000 X-Envelope-From: stephane@chazelas.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _nblcust.gandi.net designates 217.70.178.231 as permitted sender) Date: Tue, 14 Apr 2020 07:18:16 +0100 From: Stephane Chazelas To: zsh-workers@zsh.org Subject: Re: glob qualifier '-' doesn't work correctly on dangling symlinks Message-ID: <20200414061816.5qfbjyc6w3x34wcz@chazelas.org> Mail-Followup-To: zsh-workers@zsh.org References: <20200411203714.wupg6wmd7b7xch2w@chazelas.org> <20200411234817.GA1737986@zira.vinc17.org> <20200412012155.7954a35f@tarpaulin.shahaf.local2> <20200412021722.GA1748686@zira.vinc17.org> <20200412070930.etfzj6j2qvd5em7b@chazelas.org> <20200412142544.GA1783815@zira.vinc17.org> <20200412173448.rl3wttigdx5t5wcn@chazelas.org> <20200412233845.GB1831017@zira.vinc17.org> <20200413142257.orwzb4jrgmf7gpoi@chazelas.org> <20200413214149.GA2644627@zira.vinc17.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200413214149.GA2644627@zira.vinc17.org> User-Agent: NeoMutt/20180716 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