GNU bug report logs - #4819
file-truename's undocumented behavior

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 4819 in the body.
You can then email your comments to 4819 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: MON KEY <monkey <at> sandpframing.com>
To: bug-gnu-emacs <at> gnu.org
Subject: file-truename's undocumented behavior
Date: Tue, 27 Oct 2009 20:28:40 -0400

This form returns a value.
(file-truename "")

WHY?
I just spent 2 1/2 hours in a break-loop three functions away trying to debug
_undocumented_ behavior.

GNU Emacs 23.1.50.1 (i386-mingw-nt5.1.2600)
 of 2009-06-30 on LENNART-69DE564 (patched)

Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: MON KEY <monkey <at> sandpframing.com>
Cc: 4819 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#4819: file-truename's undocumented behavior
Date: Tue, 27 Oct 2009 21:52:24 -0400

> This form returns a value.
> (file-truename "")

> WHY?

Why not?  What value did you expect?

> I just spent 2 1/2 hours in a break-loop three functions away trying
> to debug _undocumented_ behavior.

Which part of the documentation do you think this behavior contradicts?


        Stefan

Message #20 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: MON KEY <monkey <at> sandpframing.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 4819 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#4819: file-truename's undocumented behavior
Date: Wed, 28 Oct 2009 16:01:32 -0400

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

On Tue, Oct 27, 2009 at 9:52 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> This form returns a value.
>> (file-truename "")
>
>> WHY?
>
> Why not?  What value did you expect?
I assumed nil.
I'm not sure what I would expect esp. having since noted that:

(file-relative-name "")     ;=> "."
(file-exists-p "")          ;=> t
(file-readable-p "")        ;=> t
(file-directory-p "")       ;=> t
(file-name-as-directory "") ;=> "./"

However, discarding the state of my "least surprisedness", I would _not_ expect
that file-truename would step all over the match-data, and where it does so not
before first:

a) Using string-match-p where applicable;

b) Noting that it does so in the documention. i.e. as per `split-string'.

>
>> I just spent 2 1/2 hours in a break-loop three functions away trying
>> to debug _undocumented_ behavior.
>
> Which part of the documentation do you think this behavior contradicts?
>

This part:
 (file-name-absolute-p "") ;=> nil
 (file-symlink-p "")       ;=> nil

On which systems/platforms does "" denote an absolute filename?
On which systems/platforms does "" denote a symbolic link for a filename?

,---- (documentation 'file-truename)
| Return the truename of filename, which should be absolute.
| The truename of a file name is found by chasing symbolic links
| both at the level of the file and at the level of the directories
| containing it, until no links are left at any level.
`----

And, this other part where documentation:

a) Neglects to mention that this function invokes repeatedly invokes
   `string-match' twice per invokation.

{...} (unless (string-match "[[*?]" filename)
      (string-match "~[^/]*/?" filename)) {...}

{...} ((and (string= (substring filename 0 1) "~")
       (string-match "~[^/]*/?" filename)) {...}

b) Neglects to mention that the remaining args COUNTER and PREV-DIRS are
   iterative counters for operations on recursive calls.  Which means that where
   file-truename recurses `string-match' may be invoked more than twice times.

   ,---- Comments in the definition of `file-truename' in files.el
   |;; Don't document the optional arguments.
   |;; COUNTER and PREV-DIRS are only used in recursive calls.
   |;; COUNTER can be a cons cell whose car is the count of how many
   |;; more links to chase before getting an error.
   |;; PREV-DIRS can be a cons cell whose car is an alist
   |;; of truenames we've just recently computed.
   `----
It was only as a late afterthought that I realized that it wasn't _MY-CODE+
clobbering the match-data - as is usual : ) but maybe Emacs'. The realization
was elusive because the recursion only happens when the w32 conditional which
drops into a recursion predicated on the return value of `w32-long-file-name'.

{...} (setq filename (concat (file-truename rest) missing)) {...}

Why not mention in the docs that on w32 `w32-long-file-name' may be a more
suitable alternative esp. as it is a primitive and as it will expand "8.3 DOS"
short name aliases in the process. (Again, per _existing_ comments in body of
`file-truename's definition).

I understand _why_ the optional args have been left undocumented - they are
essentially hacks which the user shouldn't rely on. However, I don't understand
_why_ the w32 hack isn't made known esp. where the hack is applicable for user
code and is indicated as the preferred solution...

W/re the string-match vs. string-matchp doesn't the following accomplish the
same:
;;; ==============================

*** /files.el-p 2009-10-28 15:49:38.843750000 -0400
--- /emacs/lisp/files.el	2009-06-30 15:51:22.000000000 -0400
***************
*** 893,904 ****
  	 (setq filename (expand-file-name filename))
  	 (if (string= filename "")
  	     (setq filename "/")))
!         ((and (string= (substring filename 0 1) "~")
!               (string-match-p "~[^/]*/?" filename))
!          (string-match "~[^/]*/?" filename)
!          (let ((first-part
!                 (substring filename 0 (match-end 0)))
!                (rest (substring filename (match-end 0))))	
  	   (setq filename (concat (expand-file-name first-part) rest)))))

    (or counter (setq counter (list 100)))
--- 893,903 ----
  	 (setq filename (expand-file-name filename))
  	 (if (string= filename "")
  	     (setq filename "/")))
! 	((and (string= (substring filename 0 1) "~")
! 	      (string-match "~[^/]*/?" filename))
! 	 (let ((first-part
! 		(substring filename 0 (match-end 0)))
! 	       (rest (substring filename (match-end 0))))
  	   (setq filename (concat (expand-file-name first-part) rest)))))

    (or counter (setq counter (list 100)))
***************
*** 930,936 ****
  	(if handler
  	    (setq filename (funcall handler 'file-truename filename))
  	  ;; If filename contains a wildcard, newname will be the old name.
! 	  (unless (string-match-p "[[*?]" filename)
  	    ;; If filename exists, use the long name.  If it doesn't exist,
              ;; drill down until we find a directory that exists, and use
              ;; the long name of that, with the extra non-existent path
--- 929,935 ----
  	(if handler
  	    (setq filename (funcall handler 'file-truename filename))
  	  ;; If filename contains a wildcard, newname will be the old name.
! 	  (unless (string-match "[[*?]" filename)
  	    ;; If filename exists, use the long name.  If it doesn't exist,
              ;; drill down until we find a directory that exists, and use
              ;; the long name of that, with the extra non-existent path

[diff.files.el (application/octet-stream, attachment)]

Message #30 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: MON KEY <monkey <at> sandpframing.com>
Cc: 4819 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#4819: file-truename's undocumented behavior
Date: Wed, 28 Oct 2009 20:37:53 -0400

> I assumed nil.

That would be very unexpected, since file-truename otherwise always
returns a string when passed a string.

> However, discarding the state of my "least surprisedness", I would
> _not_ expect that file-truename would step all over the match-data,
> and where it does so not before first:

Most functions don't preserve the match-data, and even more so for
functions that manipulate strings or buffers.

> b) Noting that it does so in the documention. i.e. as per `split-string'.

It's the other way around: the few functions that preserve the
match-data should be documented as such (better yet: the byte-compiler
should be taught about them, so it can detect when we use the
match-data after it got clobbered).

>>> I just spent 2 1/2 hours in a break-loop three functions away trying
>>> to debug _undocumented_ behavior.
>> Which part of the documentation do you think this behavior contradicts?

> This part:
>  (file-name-absolute-p "") ;=> nil
>  (file-symlink-p "")       ;=> nil

That's not a part of the documentation.

> Why not mention in the docs that on w32 `w32-long-file-name' may be
> a more suitable alternative esp. as it is a primitive and as it will
> expand "8.3 DOS" short name aliases in the process. (Again, per
> _existing_ comments in body of `file-truename's definition).

Elisp should generally not be w32-specific, so ratehr than use
w32-long-file-name we should maybe change
file-truename correspondingly.  That doesn't mean I think it's the right
thing to do: I know next to nothing about this issue.

> !         ((and (string= (substring filename 0 1) "~")
> !               (string-match-p "~[^/]*/?" filename))
> !          (string-match "~[^/]*/?" filename)
> !          (let ((first-part
> !                 (substring filename 0 (match-end 0)))
> !                (rest (substring filename (match-end 0))))

What's the point?  If you're going to use string-match in the end, you
might as well do it right away.


        Stefan

Message #40 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, 4819 <at> debbugs.gnu.org
Cc: MON KEY <monkey <at> sandpframing.com>, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#4819: file-truename's undocumented behavior
Date: Thu, 29 Oct 2009 01:56:26 +0100

On Thu, Oct 29, 2009 at 1:37 AM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>
>> Why not mention in the docs that on w32 `w32-long-file-name' may be
>> a more suitable alternative esp. as it is a primitive and as it will
>> expand "8.3 DOS" short name aliases in the process. (Again, per
>> _existing_ comments in body of `file-truename's definition).
>
> Elisp should generally not be w32-specific, so ratehr than use
> w32-long-file-name we should maybe change
> file-truename correspondingly.  That doesn't mean I think it's the right
> thing to do: I know next to nothing about this issue.


It already calls w32-long-file-name. (I am not sure what MON means.)

Message #50 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: MON KEY <monkey <at> sandpframing.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 4819 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#4819: file-truename's undocumented behavior
Date: Fri, 6 Nov 2009 19:01:28 -0500

Stefan,
I'm very sorry for the delayed response things have been hectic of late.

On Wed, Oct 28, 2009 at 7:37 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> I assumed nil.
>
> That would be very unexpected, since file-truename otherwise always
> returns a string when passed a string.

Yes, understood; most likely my assumptions are predicated by these seemingly
contradictory behaviors:

(file-name-absolute-p "") ;=> nil
(file-symlink-p "")       ;=> nil

>
> It's the other way around: the few functions that preserve the
> match-data should be documented as such (better yet: the byte-compiler
> should be taught about them, so it can detect when we use the
> match-data after it got clobbered).

No argument there :)

>>> Which part of the documentation do you think this behavior contradicts?
>
>> This part:
>>  (file-name-absolute-p "") ;=> nil
>>  (file-symlink-p "")       ;=> nil
>
> That's not a part of the documentation.

You're right. None the less, this behaviour does contradict behaviour indicated
by said docs.

> Elisp should generally not be w32-specific, so ratehr than use
> w32-long-file-name we should maybe change
> file-truename correspondingly.  That doesn't mean I think it's the right
> thing to do: I know next to nothing about this issue.

Best I can gather the existing w32 conditional branch has been around for a long
time.  i.e. the email address in the comments carry a {...}@harlequin.co.uk
domain.

>
>> !         ((and (string= (substring filename 0 1) "~")
>> !               (string-match-p "~[^/]*/?" filename))
>> !          (string-match "~[^/]*/?" filename)
>> !          (let ((first-part
>> !                 (substring filename 0 (match-end 0)))
>> !                (rest (substring filename (match-end 0))))
>
> What's the point?

To avoid setting the match-data b/c it _is not_ necessarily going to be used per
the conditional.

> If you're going to use string-match in the end, you might as well do it right
> away.

This is wrong.
Though, it may explain how/why the existing situation persists :)

>        Stefan
>
s_P

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

From: Glenn Morris <rgm <at> gnu.org>
To: 4819-done <at> debbugs.gnu.org
Subject: Re: bug#4819: file-truename's undocumented behavior
Date: Sat, 09 Jul 2011 01:51:06 -0400

I don't see a need to keep open this particular report, which was marked
"wontfix" some time ago.

Previous Next

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