GNU bug report logs - #17073
24.3.50; file-symlink-p doesn't return t as described in the doc

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17073 in the body.
You can then email your comments to 17073 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; file-symlink-p doesn't return t as described in the doc
Date: Sun, 23 Mar 2014 20:33:08 +0100

Hello,

the doc of `file-symlink-p' says:

This function returns t when given the name of a symlink that
points to a nonexistent file.

But this is not the case here.  Instead, it returns the resolved file
name, which is a nonexisting file.

This is with emacs -Q, and with all Emacs versions I tried, which were
23, 24 that come with Debian testing, and a recent built from trunk.

Tested on Debian testing. 


Thanks,

Michael.



In GNU Emacs 24.3.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.7)
 of 2014-03-14 on drachen
Windowing system distributor `The X.Org Foundation', version 11.0.11500000
System Description:	Debian GNU/Linux testing (jessie)

Message #8 received at 17073 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 17073 <at> debbugs.gnu.org
Subject: Re: bug#17073: 24.3.50;
 file-symlink-p doesn't return t as described in the doc
Date: Sun, 23 Mar 2014 19:34:18 -0400

Michael Heerdegen wrote:

> the doc of `file-symlink-p' says:
>
> This function returns t when given the name of a symlink that
> points to a nonexistent file.
>
> But this is not the case here.  Instead, it returns the resolved file
> name, which is a nonexisting file.

Then I guess it means t in the sense of non-nil.

Message #13 received at 17073-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 17073-done <at> debbugs.gnu.org
Subject: Re: bug#17073: 24.3.50;
 file-symlink-p doesn't return t as described in the doc
Date: Sun, 23 Mar 2014 19:39:02 -0400

Version: 24.4

Doc fixed.

Message #16 received at 17073 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: 17073 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>, 
 Michael Heerdegen <michael_heerdegen <at> web.de>
Subject: Re: bug#17073: 24.3.50; file-symlink-p doesn't return t as described
 in the doc
Date: Mon, 24 Mar 2014 01:25:36 +0100

Perhaps it's me, but I don't find the doc for this function (in the
elisp reference) particularly clear

 -- Function: file-symlink-p filename
     If the file FILENAME is a symbolic link, the `file-symlink-p'
     function returns the (non-recursive) link target as a string.

Here it agrees with your interpretation, so at least that is clear.

     (Determining the file name that the link points to from the target
     is nontrivial.)  First, this function recursively follows symbolic
     links at all levels of parent directories.

IIUC, it's saying (above) that it does not follow symbolic links to
files recursively. But (below) that it does follow recursively
symbolic links to directories, until it finds a file (or a symbolic
link to a file). Is that?

   J

Message #19 received at 17073 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: michael_heerdegen <at> web.de, rgm <at> gnu.org, 17073 <at> debbugs.gnu.org
Subject: Re: bug#17073: 24.3.50;
 file-symlink-p doesn't return t as described in the doc
Date: Mon, 24 Mar 2014 05:52:31 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 24 Mar 2014 01:25:36 +0100
> 
> Perhaps it's me, but I don't find the doc for this function (in the
> elisp reference) particularly clear
> 
>  -- Function: file-symlink-p filename
>      If the file FILENAME is a symbolic link, the `file-symlink-p'
>      function returns the (non-recursive) link target as a string.
> 
> Here it agrees with your interpretation, so at least that is clear.
> 
>      (Determining the file name that the link points to from the target
>      is nontrivial.)  First, this function recursively follows symbolic
>      links at all levels of parent directories.
> 
> IIUC, it's saying (above) that it does not follow symbolic links to
> files recursively. But (below) that it does follow recursively
> symbolic links to directories, until it finds a file (or a symbolic
> link to a file). Is that?

The difference is between the file (a.k.a. "basename") part of the
file name, and the leading directories part.  And yes, it is true.

Message #22 received at 17073 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, Glenn Morris <rgm <at> gnu.org>,
 17073 <at> debbugs.gnu.org
Subject: Re: bug#17073: 24.3.50; file-symlink-p doesn't return t as described
 in the doc
Date: Mon, 24 Mar 2014 05:00:34 +0100

On Mon, Mar 24, 2014 at 4:52 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> The difference is between the file (a.k.a. "basename") part of the
> file name, and the leading directories part.  And yes, it is true.

Well, as I said, I think that docstring could benefit from a little love.

    J

Message #25 received at 17073 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, Glenn Morris <rgm <at> gnu.org>,
 17073 <at> debbugs.gnu.org
Subject: Re: bug#17073: 24.3.50; file-symlink-p doesn't return t as described
 in the doc
Date: Mon, 24 Mar 2014 05:02:11 +0100

On Mon, Mar 24, 2014 at 5:00 AM, Juanma Barranquero <lekktu <at> gmail.com> wrote:

> Well, as I said, I think that docstring could benefit from a little love.

s/docstring/manual entry/

Message #28 received at 17073 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: michael_heerdegen <at> web.de, rgm <at> gnu.org, 17073 <at> debbugs.gnu.org
Subject: Re: bug#17073: 24.3.50;
 file-symlink-p doesn't return t as described in the doc
Date: Mon, 24 Mar 2014 18:49:11 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 24 Mar 2014 05:00:34 +0100
> Cc: 17073 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>, 
> 	Michael Heerdegen <michael_heerdegen <at> web.de>
> 
> On Mon, Mar 24, 2014 at 4:52 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > The difference is between the file (a.k.a. "basename") part of the
> > file name, and the leading directories part.  And yes, it is true.
> 
> Well, as I said, I think that docstring could benefit from a little love.

Not sure which part needs love.  Could you perhaps point out the
unclear parts?

Message #31 received at 17073 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 17073 <at> debbugs.gnu.org
Subject: Re: bug#17073: 24.3.50; file-symlink-p doesn't return t as described
 in the doc
Date: Mon, 24 Mar 2014 18:01:04 +0100

On Mon, Mar 24, 2014 at 5:49 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Not sure which part needs love.  Could you perhaps point out the
> unclear parts?

  First, this function recursively follows symbolic
     links at all levels of parent directories.

On one hand, though I suppose "First, this function recursively
follows..." means "This function, first of all, recursively
follows...", my instinct is that it is the start of an enumeration, so
I expect a "Second, it ...".

On the other hand, you've explained that this:

    If the file FILENAME is a symbolic link, the `file-symlink-p'
     function returns the (non-recursive) link target as a string.

talks about the 'file (a.k.a. "basename") part of the file name', and this

  First, this function recursively follows symbolic
     links at all levels of parent directories.

talks about the 'leading directories part'. Well, I don't find that clear.

   J

Message #34 received at 17073 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: michael_heerdegen <at> web.de, 17073 <at> debbugs.gnu.org
Subject: Re: bug#17073: 24.3.50;
 file-symlink-p doesn't return t as described in the doc
Date: Tue, 25 Mar 2014 18:10:12 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 24 Mar 2014 18:01:04 +0100
> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 17073 <at> debbugs.gnu.org
> 
> On Mon, Mar 24, 2014 at 5:49 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > Not sure which part needs love.  Could you perhaps point out the
> > unclear parts?
> 
>   First, this function recursively follows symbolic
>      links at all levels of parent directories.
> 
> On one hand, though I suppose "First, this function recursively
> follows..." means "This function, first of all, recursively
> follows...", my instinct is that it is the start of an enumeration, so
> I expect a "Second, it ...".
> 
> On the other hand, you've explained that this:
> 
>     If the file FILENAME is a symbolic link, the `file-symlink-p'
>      function returns the (non-recursive) link target as a string.
> 
> talks about the 'file (a.k.a. "basename") part of the file name', and this
> 
>   First, this function recursively follows symbolic
>      links at all levels of parent directories.
> 
> talks about the 'leading directories part'. Well, I don't find that clear.

I tried to clarify and improve the documentation in revision 116859 on
the emacs-24 branch, please take a look.

Message #37 received at 17073 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 17073 <at> debbugs.gnu.org
Subject: Re: bug#17073: 24.3.50; file-symlink-p doesn't return t as described
 in the doc
Date: Tue, 25 Mar 2014 17:29:26 +0100

On Tue, Mar 25, 2014 at 5:10 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> I tried to clarify and improve the documentation in revision 116859 on
> the emacs-24 branch, please take a look.

Superb!  Thanks.

Message #40 received at 17073 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: michael_heerdegen <at> web.de, 17073 <at> debbugs.gnu.org
Subject: Re: bug#17073: 24.3.50;
 file-symlink-p doesn't return t as described in the doc
Date: Tue, 25 Mar 2014 20:03:16 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Tue, 25 Mar 2014 17:29:26 +0100
> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 17073 <at> debbugs.gnu.org
> 
> On Tue, Mar 25, 2014 at 5:10 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > I tried to clarify and improve the documentation in revision 116859 on
> > the emacs-24 branch, please take a look.
> 
> Superb!  Thanks.

Thanks.  Can this be closed, then?

Message #43 received at 17073-done <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 17073-done <at> debbugs.gnu.org
Subject: Re: bug#17073: 24.3.50; file-symlink-p doesn't return t as described
 in the doc
Date: Tue, 25 Mar 2014 19:04:32 +0100

Version: 24.3.50

> Can this be closed, then?

Sure. Done.

Message #46 received at 17073 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 17073 <at> debbugs.gnu.org
Subject: Re: bug#17073: 24.3.50;
 file-symlink-p doesn't return t as described in the doc
Date: Tue, 25 Mar 2014 19:37:43 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Thanks.  Can this be closed, then?

The changes in the manual look great, thanks.

Sorry if this is a dumb question, but:

  If the leading directories of @var{filename} include symbolic links,
  this function recursively follows them.

Is this obvious? If not - doesn't it also belong in the docstring?

Thanks,
Michael.

Message #49 received at 17073 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: lekktu <at> gmail.com, 17073 <at> debbugs.gnu.org
Subject: Re: bug#17073: 24.3.50;
 file-symlink-p doesn't return t as described in the doc
Date: Tue, 25 Mar 2014 21:02:20 +0200

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Juanma Barranquero <lekktu <at> gmail.com>,  17073 <at> debbugs.gnu.org
> Date: Tue, 25 Mar 2014 19:37:43 +0100
> 
>   If the leading directories of @var{filename} include symbolic links,
>   this function recursively follows them.
> 
> Is this obvious?

Hard to say.  I think it's pretty obvious to those who are used to
semantics of symlinks (I actually find strange and even confusing the
fact that the manual insists on telling which functions follow links
and in which parts of the filename).  For those who are not used to
symlinks, I'm pretty sure even the above sentence does not say enough.

> If not - doesn't it also belong in the docstring?

Well, we don't normally say about each file-related function whether
it does or doesn't follow symlinks.  So why this one?

Message #52 received at 17073 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 17073 <at> debbugs.gnu.org
Subject: Re: bug#17073: 24.3.50;
 file-symlink-p doesn't return t as described in the doc
Date: Tue, 25 Mar 2014 20:21:44 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> >   If the leading directories of @var{filename} include symbolic links,
> >   this function recursively follows them.
> > 
> > Is this obvious?
>
> Hard to say.  I think it's pretty obvious to those who are used to
> semantics of symlinks

I understand it now after thinking about it a bit. Yes, it's quite
obvious.

> > If not - doesn't it also belong in the docstring?
>
> Well, we don't normally say about each file-related function whether
> it does or doesn't follow symlinks.  So why this one?

Ok, I agree.  So I too think we are ready here.


Thanks,

Michael.

Message #55 received at 17073 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, lekktu <at> gmail.com,
 17073 <at> debbugs.gnu.org
Subject: Re: bug#17073: 24.3.50;
 file-symlink-p doesn't return t as described in the doc
Date: Tue, 25 Mar 2014 20:41:53 -0400

>> If the leading directories of @var{filename} include symbolic links,
>> this function recursively follows them.
>> Is this obvious?
> Hard to say.  I think it's pretty obvious to those who are used to
> semantics of symlinks (I actually find strange and even confusing the
> fact that the manual insists on telling which functions follow links
> and in which parts of the filename).  For those who are not used to
> symlinks, I'm pretty sure even the above sentence does not say enough.

I think the sentence is more confusing than helpful.  To me it makes it
sound like there something special going on, whereas it's just business
as usual.  And as you say, for people not used to the semantics of
symlinks it's not helpful either (and putting it in file-symlink-p is
confusing since it gives the impression that symlinks only affect
file-symlink-p).


        Stefan

Message #58 received at 17073 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: michael_heerdegen <at> web.de, lekktu <at> gmail.com, 17073 <at> debbugs.gnu.org
Subject: Re: bug#17073: 24.3.50;
 file-symlink-p doesn't return t as described in the doc
Date: Wed, 26 Mar 2014 05:53:25 +0200

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, lekktu <at> gmail.com,
>         17073 <at> debbugs.gnu.org
> Date: Tue, 25 Mar 2014 20:41:53 -0400
> 
> >> If the leading directories of @var{filename} include symbolic links,
> >> this function recursively follows them.
> >> Is this obvious?
> > Hard to say.  I think it's pretty obvious to those who are used to
> > semantics of symlinks (I actually find strange and even confusing the
> > fact that the manual insists on telling which functions follow links
> > and in which parts of the filename).  For those who are not used to
> > symlinks, I'm pretty sure even the above sentence does not say enough.
> 
> I think the sentence is more confusing than helpful.  To me it makes it
> sound like there something special going on, whereas it's just business
> as usual.

But the same is true for all the other places in files.texi which
document what functions follow symlinks and in which part(s) of their
arguments.  This one is just one such place, one of many.

Previous Next

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