GNU bug report logs - #56673
26.3; Doc of `file-equal-p'

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#56673: closed (26.3; Doc of `file-equal-p')
Date: Thu, 21 Jul 2022 06:00:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Thu, 21 Jul 2022 08:59:35 +0300
with message-id <83o7xjngzc.fsf <at> gnu.org>
and subject line Re: bug#56673: 26.3; Doc of `file-equal-p'
has caused the debbugs.gnu.org bug report #56673,
regarding 26.3; Doc of `file-equal-p'
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
56673: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56673
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Drew Adams <drew.adams <at> oracle.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 26.3; Doc of `file-equal-p'
Date: Wed, 20 Jul 2022 20:41:45 +0000

1. I don't understand this part of the doc (in both doc string and
manual):

  If FILE1 or FILE2 does not exist, the return value is unspecified.

What's that about?  Looking at the code, it looks like if either doesn't
exist then its own part in the test is just nil.

OK, if there's a file handler then that case could be unspecified.  But
if there's a file handler then the result could always be unspecified,
no?  (The handler doc, if there is one, presumably would "specify" what
its handling of `file-equal-p' does/means, however.)

Is that caveat only about the case where there's a file handler
involved?  If so, it would be more helpful to just say so.

But if there's no file handler, how can evaluating this give something
unspecified?

(let (f1-attr f2-attr)
  (and (setq f1-attr (file-attributes (file-truename file1)))
       (setq f2-attr (file-attributes (file-truename file2)))
       (equal f1-attr f2-attr)))

`file-attributes' just returns nil if the file can't be opened.

In what case(s) is the result unspecified because one or both file
doesn't exist?

2. How about adding this sentence from the manual to the doc string
(also)?

  This is similar to comparing their truenames, except that remote file
  names are also handled in an appropriate manner.

In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor `Microsoft Corp.', version 10.0.19044
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

[Message part 3 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 56673-done <at> debbugs.gnu.org
Subject: Re: bug#56673: 26.3; Doc of `file-equal-p'
Date: Thu, 21 Jul 2022 08:59:35 +0300

> From: Drew Adams <drew.adams <at> oracle.com>
> Date: Wed, 20 Jul 2022 20:41:45 +0000
> 
> 1. I don't understand this part of the doc (in both doc string and
> manual):
> 
>   If FILE1 or FILE2 does not exist, the return value is unspecified.
> 
> What's that about?

It means the result could be anything: nil or non-nil, and you
shouldn't expect anything specific.  IOW, don't call this function
unless both files exist.

> In what case(s) is the result unspecified because one or both file
> doesn't exist?

All of them.  There was a long discussion of this in bug#10489, and
I'm not interested in reopening it.

> 2. How about adding this sentence from the manual to the doc string
> (also)?
> 
>   This is similar to comparing their truenames, except that remote file
>   names are also handled in an appropriate manner.

The doc string already says that, albeit with different words.

Closing.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.