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 14369 invoked from network); 14 Apr 2020 18:00:40 -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 18:00:40 -0000 Received: (qmail 26153 invoked by alias); 14 Apr 2020 18:00:28 -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: 45697 Received: (qmail 10114 invoked by uid 1010); 14 Apr 2020 18:00:28 -0000 X-Qmail-Scanner-Diagnostics: from joooj.vinc17.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(155.133.131.76):SA:0(-1.9/5.0):. Processed in 3.991041 secs); 14 Apr 2020 18:00:28 -0000 X-Envelope-From: vincent@vinc17.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at vinc17.net does not designate permitted sender hosts) Date: Tue, 14 Apr 2020 19:59:45 +0200 From: Vincent Lefevre To: zsh-workers@zsh.org Subject: Re: glob qualifier '-' doesn't work correctly on dangling symlinks Message-ID: <20200414175945.GA2742640@zira.vinc17.org> Mail-Followup-To: zsh-workers@zsh.org References: <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> <20200414061816.5qfbjyc6w3x34wcz@chazelas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200414061816.5qfbjyc6w3x34wcz@chazelas.org> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/1.12.1+33 (6a74e24e) vl-117499 (2019-06-23) On 2020-04-14 07:18:16 +0100, Stephane Chazelas wrote: > 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. Note that "unambiguous" does not necessarily mean that the result is known. > 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. I've said that for ELOOP (here, symloop/foo), it should be fine to regard this as "not an error". This does not mean that the opposite is necessarily wrong. IMHO, this is just a bad choice. IMHO, the fact that it returns non-zero for /etc/passwd/foo is a bug. > What should the outcome be for ESYS123 error code? It seems non-standard, thus an error (unless the implementation knows what it means and the consequence on the existence of the file). Note that in any case, an error is always possible, even when not expected. For instance, it could be due to a network issue in case of NFS, and more generally some hardware failure. Script must be able to handle errors at any time. > To me, the best approach is zsh's where *(-@) reports *all* > broken links, broken meaning "whose target cannot be resolved". Since zsh regards "permission denied" errors as non-matching (for instance, on my machine, /r*/* expands to objects under /run, with no errors, even though the /root directory is not accessible), I think it is fine that here, EACCES errors (permission denied) be regarded as non-existing. But IMHO, "serious" errors such as ENOMEM should be reported as such with globbing (in general, not just for symlink resolution), i.e. zsh should not execute the command and should report an error instead, like with a "bad pattern" error. [...] > 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. Is this POSIX compliant? If it is, I would say that it is a bug. > 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). I would say that this is a also a bug. However, perhaps not since how the resolution is done is not specified. > There's also the case of case insensitive or unicode-normalizing > file systems. POSIX compliant? -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)