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 24586 invoked from network); 13 Apr 2020 21:42:34 -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; 13 Apr 2020 21:42:34 -0000 Received: (qmail 17615 invoked by alias); 13 Apr 2020 21:42:29 -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: 45691 Received: (qmail 25572 invoked by uid 1010); 13 Apr 2020 21:42: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 1.797505 secs); 13 Apr 2020 21:42: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: Mon, 13 Apr 2020 23:41:49 +0200 From: Vincent Lefevre To: zsh-workers@zsh.org Subject: Re: glob qualifier '-' doesn't work correctly on dangling symlinks Message-ID: <20200413214149.GA2644627@zira.vinc17.org> Mail-Followup-To: zsh-workers@zsh.org References: <20200411191711.GA1722320@zira.vinc17.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200413142257.orwzb4jrgmf7gpoi@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-13 15:22:57 +0100, Stephane Chazelas wrote: > 2020-04-13 01:38:45 +0200, Vincent Lefevre: > [...] > > > Well, as seen in the varying interpretations made by the various > > > implementations, it is not that clear. How do you determine > > > whether a file exists or not? What does "exist" mean? > > > > You necessarily know it, or that's an error case (permission denied > > or whatever). The behavior may not be clear in case of error, but > > one can expect at least a non-zero exit status: > [...] > > Are you saying that EACCES is an "error" but ENOENT is not? Yes, because getting EACCES implies that the system could not determine whether the file exists or not. With ENOENT, the system could determine that the file does not exist. > How about ENOTDIR, ELOOP? None of /etc/passwd/foo, /etc/pesswd/foo, > symloop/foo or /root/foo exist on my system, a stat() on a symlink > to those would return ENOTDIR, ENOENT, ELOOP, EACCES. On which one > should find -L return with a non-zero exit status? ENOTDIR: in the symlink resolution, the system got a path prefix that is not a directory, and this implies that the file cannot exist. Thus this should not be regarded as an error (since the target file does not exist, the file information and type is for the link itself). ENOENT: Not an error, as this means that the target file does not exist; so the file information and type is for the link itself. ELOOP: This can imply two possibilities: either there is really a loop, so that the symlink does not resolve to a file, or the number of redirections is too large, but in this case, I would say that this also means that the symlink does not resolve to a file because a probably fixed system limit has been reached. Therefore it should be fine to regard this as "not an error", like ENOTDIR and ENOENT. I think that regarding this as an error would be bad because even with sufficient permissions (e.g. as root) and resources, this could make "find" fail every time, thus would not be very helpful. EACCES: an error since the system could not determine whether /root/foo exists or not, due to the lack of permissions. ENOMEM would also be an error, assuming that this could occur on any symlink. > 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). > [...] > > -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. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)