From unknown Fri Jun 20 20:11:19 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4819: file-truename's undocumented behavior Reply-To: MON KEY , 4819@debbugs.gnu.org Resent-From: MON KEY Original-Sender: stan@derbycityprints.com Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Wed, 28 Oct 2009 00:35:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: report 4819 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.125668973018668 (code B ref -1); Wed, 28 Oct 2009 00:35:04 +0000 Received: (at submit) by emacsbugs.donarmstrong.com; 28 Oct 2009 00:28:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=AWL,MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9S0Smlv018665 for ; Tue, 27 Oct 2009 17:28:50 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N2wP9-0004tq-UT for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 20:28:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N2wP3-0004nd-Dn for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 20:28:45 -0400 Received: from [199.232.76.173] (port=51311 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N2wP3-0004nV-BR for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 20:28:41 -0400 Received: from mail-yw0-f194.google.com ([209.85.211.194]:33185) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N2wP3-0007kG-14 for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 20:28:41 -0400 Received: by ywh32 with SMTP id 32so241487ywh.14 for ; Tue, 27 Oct 2009 17:28:40 -0700 (PDT) MIME-Version: 1.0 Sender: stan@derbycityprints.com Received: by 10.150.44.2 with SMTP id r2mr27843987ybr.77.1256689720441; Tue, 27 Oct 2009 17:28:40 -0700 (PDT) Date: Tue, 27 Oct 2009 20:28:40 -0400 X-Google-Sender-Auth: 2daeca6eea06147a Message-ID: From: MON KEY To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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) From unknown Fri Jun 20 20:11:19 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4819: file-truename's undocumented behavior Reply-To: Stefan Monnier , 4819@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Wed, 28 Oct 2009 01:55:09 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4819 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.125669475327743 (code B ref -1); Wed, 28 Oct 2009 01:55:09 +0000 Received: (at submit) by emacsbugs.donarmstrong.com; 28 Oct 2009 01:52:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9S1qUfV027736 for ; Tue, 27 Oct 2009 18:52:31 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N2xiA-00076v-9t for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 21:52:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N2xi5-0006xs-Or for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 21:52:29 -0400 Received: from [199.232.76.173] (port=50623 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N2xi5-0006xf-LB for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 21:52:25 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.183]:29845 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N2xi5-00033u-AU for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 21:52:25 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwEAOdA50pLd/xb/2dsb2JhbACBT9hOhD8Egl+FXQ X-IronPort-AV: E=Sophos;i="4.44,636,1249272000"; d="scan'208";a="48276094" Received: from 75-119-252-91.dsl.teksavvy.com (HELO ceviche.home) ([75.119.252.91]) by ironport2-out.pppoe.ca with ESMTP; 27 Oct 2009 21:52:24 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 3323D70019; Tue, 27 Oct 2009 21:52:24 -0400 (EDT) From: Stefan Monnier To: MON KEY Cc: 4819@debbugs.gnu.org, bug-gnu-emacs@gnu.org Message-ID: References: Date: Tue, 27 Oct 2009 21:52:24 -0400 In-Reply-To: (MON KEY's message of "Tue, 27 Oct 2009 20:28:40 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. > 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 From unknown Fri Jun 20 20:11:19 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4819: file-truename's undocumented behavior Reply-To: MON KEY , 4819@debbugs.gnu.org Resent-From: MON KEY Original-Sender: stan@derbycityprints.com Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Wed, 28 Oct 2009 20:10:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4819 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.125676010517264 (code B ref -1); Wed, 28 Oct 2009 20:10:04 +0000 Received: (at submit) by emacsbugs.donarmstrong.com; 28 Oct 2009 20:01:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.7 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MDO_CABLE_TV3 autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9SK1g5X017261 for ; Wed, 28 Oct 2009 13:01:43 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3EiD-0005Io-Km for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 16:01:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3Ei7-00057V-2C for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 16:01:39 -0400 Received: from [199.232.76.173] (port=58430 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3Ei6-000570-8J for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 16:01:34 -0400 Received: from mail-yw0-f194.google.com ([209.85.211.194]:39664) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N3Ei5-00047L-Qd for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 16:01:34 -0400 Received: by ywh32 with SMTP id 32so1006950ywh.14 for ; Wed, 28 Oct 2009 13:01:32 -0700 (PDT) MIME-Version: 1.0 Sender: stan@derbycityprints.com Received: by 10.150.171.17 with SMTP id t17mr8690819ybe.303.1256760092335; Wed, 28 Oct 2009 13:01:32 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Oct 2009 16:01:32 -0400 X-Google-Sender-Auth: 28579b3c0fb5da9f Message-ID: From: MON KEY To: Stefan Monnier Cc: 4819@debbugs.gnu.org, bug-gnu-emacs@gnu.org Content-Type: multipart/mixed; boundary=000e0cd5c6c0df2f8a04770442ad X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) --000e0cd5c6c0df2f8a04770442ad Content-Type: text/plain; charset=UTF-8 On Tue, Oct 27, 2009 at 9:52 PM, Stefan Monnier 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 --000e0cd5c6c0df2f8a04770442ad Content-Type: application/octet-stream; name="diff.files.el" Content-Disposition: attachment; filename="diff.files.el" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g1ciforc0 KioqIC9maWxlcy5lbC1wIDIwMDktMTAtMjggMTU6NDk6MzguODQzNzUwMDAwIC0wNDAwCi0tLSAv ZW1hY3MvbGlzcC9maWxlcy5lbAkyMDA5LTA2LTMwIDE1OjUxOjIyLjAwMDAwMDAwMCAtMDQwMAoq KioqKioqKioqKioqKioKKioqIDg5Myw5MDQgKioqKgogIAkgKHNldHEgZmlsZW5hbWUgKGV4cGFu ZC1maWxlLW5hbWUgZmlsZW5hbWUpKQogIAkgKGlmIChzdHJpbmc9IGZpbGVuYW1lICIiKQogIAkg ICAgIChzZXRxIGZpbGVuYW1lICIvIikpKQohICAgICAgICAgKChhbmQgKHN0cmluZz0gKHN1YnN0 cmluZyBmaWxlbmFtZSAwIDEpICJ+IikKISAgICAgICAgICAgICAgIChzdHJpbmctbWF0Y2gtcCAi flteL10qLz8iIGZpbGVuYW1lKSkKISAgICAgICAgICAoc3RyaW5nLW1hdGNoICJ+W14vXSovPyIg ZmlsZW5hbWUpCiEgICAgICAgICAgKGxldCAoKGZpcnN0LXBhcnQKISAgICAgICAgICAgICAgICAg KHN1YnN0cmluZyBmaWxlbmFtZSAwIChtYXRjaC1lbmQgMCkpKQohICAgICAgICAgICAgICAgIChy ZXN0IChzdWJzdHJpbmcgZmlsZW5hbWUgKG1hdGNoLWVuZCAwKSkpKQkKICAJICAgKHNldHEgZmls ZW5hbWUgKGNvbmNhdCAoZXhwYW5kLWZpbGUtbmFtZSBmaXJzdC1wYXJ0KSByZXN0KSkpKSkKICAK ICAgIChvciBjb3VudGVyIChzZXRxIGNvdW50ZXIgKGxpc3QgMTAwKSkpCi0tLSA4OTMsOTAzIC0t LS0KICAJIChzZXRxIGZpbGVuYW1lIChleHBhbmQtZmlsZS1uYW1lIGZpbGVuYW1lKSkKICAJIChp ZiAoc3RyaW5nPSBmaWxlbmFtZSAiIikKICAJICAgICAoc2V0cSBmaWxlbmFtZSAiLyIpKSkKISAJ KChhbmQgKHN0cmluZz0gKHN1YnN0cmluZyBmaWxlbmFtZSAwIDEpICJ+IikKISAJICAgICAgKHN0 cmluZy1tYXRjaCAiflteL10qLz8iIGZpbGVuYW1lKSkKISAJIChsZXQgKChmaXJzdC1wYXJ0CiEg CQkoc3Vic3RyaW5nIGZpbGVuYW1lIDAgKG1hdGNoLWVuZCAwKSkpCiEgCSAgICAgICAocmVzdCAo c3Vic3RyaW5nIGZpbGVuYW1lIChtYXRjaC1lbmQgMCkpKSkKICAJICAgKHNldHEgZmlsZW5hbWUg KGNvbmNhdCAoZXhwYW5kLWZpbGUtbmFtZSBmaXJzdC1wYXJ0KSByZXN0KSkpKSkKICAKICAgIChv ciBjb3VudGVyIChzZXRxIGNvdW50ZXIgKGxpc3QgMTAwKSkpCioqKioqKioqKioqKioqKgoqKiog OTMwLDkzNiAqKioqCiAgCShpZiBoYW5kbGVyCiAgCSAgICAoc2V0cSBmaWxlbmFtZSAoZnVuY2Fs bCBoYW5kbGVyICdmaWxlLXRydWVuYW1lIGZpbGVuYW1lKSkKICAJICA7OyBJZiBmaWxlbmFtZSBj b250YWlucyBhIHdpbGRjYXJkLCBuZXduYW1lIHdpbGwgYmUgdGhlIG9sZCBuYW1lLgohIAkgICh1 bmxlc3MgKHN0cmluZy1tYXRjaC1wICJbWyo/XSIgZmlsZW5hbWUpCiAgCSAgICA7OyBJZiBmaWxl bmFtZSBleGlzdHMsIHVzZSB0aGUgbG9uZyBuYW1lLiAgSWYgaXQgZG9lc24ndCBleGlzdCwKICAg ICAgICAgICAgICA7OyBkcmlsbCBkb3duIHVudGlsIHdlIGZpbmQgYSBkaXJlY3RvcnkgdGhhdCBl eGlzdHMsIGFuZCB1c2UKICAgICAgICAgICAgICA7OyB0aGUgbG9uZyBuYW1lIG9mIHRoYXQsIHdp dGggdGhlIGV4dHJhIG5vbi1leGlzdGVudCBwYXRoCi0tLSA5MjksOTM1IC0tLS0KICAJKGlmIGhh bmRsZXIKICAJICAgIChzZXRxIGZpbGVuYW1lIChmdW5jYWxsIGhhbmRsZXIgJ2ZpbGUtdHJ1ZW5h bWUgZmlsZW5hbWUpKQogIAkgIDs7IElmIGZpbGVuYW1lIGNvbnRhaW5zIGEgd2lsZGNhcmQsIG5l d25hbWUgd2lsbCBiZSB0aGUgb2xkIG5hbWUuCiEgCSAgKHVubGVzcyAoc3RyaW5nLW1hdGNoICJb Wyo/XSIgZmlsZW5hbWUpCiAgCSAgICA7OyBJZiBmaWxlbmFtZSBleGlzdHMsIHVzZSB0aGUgbG9u ZyBuYW1lLiAgSWYgaXQgZG9lc24ndCBleGlzdCwKICAgICAgICAgICAgICA7OyBkcmlsbCBkb3du IHVudGlsIHdlIGZpbmQgYSBkaXJlY3RvcnkgdGhhdCBleGlzdHMsIGFuZCB1c2UKICAgICAgICAg ICAgICA7OyB0aGUgbG9uZyBuYW1lIG9mIHRoYXQsIHdpdGggdGhlIGV4dHJhIG5vbi1leGlzdGVu dCBwYXRoCg== --000e0cd5c6c0df2f8a04770442ad-- From unknown Fri Jun 20 20:11:19 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4819: file-truename's undocumented behavior Reply-To: Stefan Monnier , 4819@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Thu, 29 Oct 2009 00:45:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4819 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.125677668612121 (code B ref -1); Thu, 29 Oct 2009 00:45:04 +0000 Received: (at submit) by emacsbugs.donarmstrong.com; 29 Oct 2009 00:38:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9T0c36q012118 for ; Wed, 28 Oct 2009 17:38:05 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3J1e-00072M-8Y for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 20:38:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3J1Z-000700-NW for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 20:38:01 -0400 Received: from [199.232.76.173] (port=57510 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3J1Z-0006zw-AF for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 20:37:57 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.183]:9968 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N3J1Y-0003hT-OF for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 20:37:57 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEAMiA6EpLd/xb/2dsb2JhbACBT9oAhD8EgmSFZw X-IronPort-AV: E=Sophos;i="4.44,642,1249272000"; d="scan'208";a="48337267" Received: from 75-119-252-91.dsl.teksavvy.com (HELO pastel.home) ([75.119.252.91]) by ironport2-out.pppoe.ca with ESMTP; 28 Oct 2009 20:37:53 -0400 Received: by pastel.home (Postfix, from userid 20848) id 946D98013; Wed, 28 Oct 2009 20:37:53 -0400 (EDT) From: Stefan Monnier To: MON KEY Cc: 4819@debbugs.gnu.org, bug-gnu-emacs@gnu.org Message-ID: References: Date: Wed, 28 Oct 2009 20:37:53 -0400 In-Reply-To: (MON KEY's message of "Wed, 28 Oct 2009 16:01:32 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. > 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 From unknown Fri Jun 20 20:11:19 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4819: file-truename's undocumented behavior Reply-To: Lennart Borgman , 4819@debbugs.gnu.org Resent-From: Lennart Borgman Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Thu, 29 Oct 2009 01:05:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4819 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.125677781514190 (code B ref -1); Thu, 29 Oct 2009 01:05:05 +0000 Received: (at submit) by emacsbugs.donarmstrong.com; 29 Oct 2009 00:56:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9T0usm6014187 for ; Wed, 28 Oct 2009 17:56:55 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3JJt-0007mu-Si for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 20:56:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3JJo-0007mJ-AQ for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 20:56:52 -0400 Received: from [199.232.76.173] (port=39270 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3JJo-0007mG-4P for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 20:56:48 -0400 Received: from mail-yx0-f191.google.com ([209.85.210.191]:58183) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N3JJn-0006M0-Pr for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 20:56:47 -0400 Received: by yxe29 with SMTP id 29so1249587yxe.14 for ; Wed, 28 Oct 2009 17:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Ii9+IaHSMUW2ZEXCJqly2Gq1GnZHinEDOFxhJEv62I4=; b=tMjlQAFSKIVQhsqZ9UaTKBDx+/frhCAjV0+Y/xFN0m7Z4LsshB1B1tUNB0raEy4KB0 kI5Lef3GpcD2hH0UAu/lCGgJkq8KAQXtdLDYXyap426IaNVU+li15YeusajtC0HS81qJ +AigUOnNPKFa8eLgw9/2kKcsOj58olqGWPvg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=GqgJiPaEPDupPkfiXpOy8pCbijCvOL9voTSopVSNT8rW3i2qMBHwaOywNp5r3LQu0c YfJ3Wkr7bQTy1fQZLLJhOLuj7uOw4qarwg4yUY2v7PXu0xyv65tWZ1zl+/6lDO7yZl9d vUR16sWEe3tWOkzJLkrhjL/KQUyJj2Tw5eTm4= MIME-Version: 1.0 Received: by 10.101.34.19 with SMTP id m19mr708632anj.81.1256777806503; Wed, 28 Oct 2009 17:56:46 -0700 (PDT) In-Reply-To: References: From: Lennart Borgman Date: Thu, 29 Oct 2009 01:56:26 +0100 Message-ID: To: Stefan Monnier , 4819@debbugs.gnu.org Cc: MON KEY , bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) On Thu, Oct 29, 2009 at 1:37 AM, Stefan Monnier 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. =C2=A0That doesn't mean I think it's the r= ight > 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.) From unknown Fri Jun 20 20:11:19 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4819: file-truename's undocumented behavior Reply-To: MON KEY , 4819@debbugs.gnu.org Resent-From: MON KEY Original-Sender: stan@derbycityprints.com Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Sat, 07 Nov 2009 00:10:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4819 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.125755209711430 (code B ref -1); Sat, 07 Nov 2009 00:10:07 +0000 Received: (at submit) by emacsbugs.donarmstrong.com; 7 Nov 2009 00:01:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nA701ZiO011423 for ; Fri, 6 Nov 2009 16:01:36 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N6YkJ-0004Az-5J for bug-gnu-emacs@gnu.org; Fri, 06 Nov 2009 19:01:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N6YkE-0004AM-J8 for bug-gnu-emacs@gnu.org; Fri, 06 Nov 2009 19:01:34 -0500 Received: from [199.232.76.173] (port=37677 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N6YkE-0004AH-GI for bug-gnu-emacs@gnu.org; Fri, 06 Nov 2009 19:01:30 -0500 Received: from mail-gx0-f212.google.com ([209.85.217.212]:39454) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N6YkE-0001sW-3F for bug-gnu-emacs@gnu.org; Fri, 06 Nov 2009 19:01:30 -0500 Received: by gxk4 with SMTP id 4so1604941gxk.8 for ; Fri, 06 Nov 2009 16:01:29 -0800 (PST) MIME-Version: 1.0 Sender: stan@derbycityprints.com Received: by 10.150.118.36 with SMTP id q36mr8885016ybc.277.1257552088940; Fri, 06 Nov 2009 16:01:28 -0800 (PST) In-Reply-To: References: Date: Fri, 6 Nov 2009 19:01:28 -0500 X-Google-Sender-Auth: 08b6f39a90f94703 Message-ID: From: MON KEY To: Stefan Monnier Cc: 4819@debbugs.gnu.org, bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 16 15:44:22 2010 Received: (at control) by debbugs.gnu.org; 16 Jan 2010 20:44:22 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NWFVN-0001HK-N6 for submit@debbugs.gnu.org; Sat, 16 Jan 2010 15:44:21 -0500 Received: from pantheon-po39.its.yale.edu ([130.132.50.100]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NWFVL-0001HD-Sf for control@debbugs.gnu.org; Sat, 16 Jan 2010 15:44:20 -0500 Received: from furry (173-14-147-246-NewEngland.hfc.comcastbusiness.net [173.14.147.246]) (authenticated bits=0) by pantheon-po39.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o0GKiFUF028568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 16 Jan 2010 15:44:15 -0500 Received: by furry (Postfix, from userid 1000) id 9BFD0C05D; Sat, 16 Jan 2010 13:44:15 -0700 (MST) From: Chong Yidong To: control@debbugs.gnu.org Subject: tags 4819 + wontfix Date: Sat, 16 Jan 2010 15:44:15 -0500 Message-ID: <87aawd4w68.fsf@stupidchicken.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-Spam-Score: -3.5 (---) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.5 (---) tags 4819 + wontfix thanks From unknown Fri Jun 20 20:11:19 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.427 (Entity 5.427) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: MON KEY Subject: bug#4819: closed (Re: bug#4819: file-truename's undocumented behavior) Message-ID: References: X-Gnu-PR-Message: they-closed 4819 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: wontfix Reply-To: 4819@debbugs.gnu.org Date: Sat, 09 Jul 2011 05:52:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1310190722-18897-1" This is a multi-part message in MIME format... ------------=_1310190722-18897-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #4819: file-truename's undocumented behavior which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 4819@debbugs.gnu.org. --=20 4819: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D4819 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1310190722-18897-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 4819-done) by debbugs.gnu.org; 9 Jul 2011 05:51:14 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QfQRd-0004td-PK for submit@debbugs.gnu.org; Sat, 09 Jul 2011 01:51:13 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QfQRb-0004tP-U2 for 4819-done@debbugs.gnu.org; Sat, 09 Jul 2011 01:51:12 -0400 Received: from localhost ([127.0.0.1]:52315) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfQRW-0003vy-5k; Sat, 09 Jul 2011 01:51:06 -0400 From: Glenn Morris To: 4819-done@debbugs.gnu.org Subject: Re: bug#4819: file-truename's undocumented behavior References: X-Spook: Vickie Weaver Cohiba Baranyi Waco, Texas ammunition X-Ran: jB_="%-Q5MxJ^6WQ_8cgxccW$t58p/rkTqW|FVv%4u9<\R+$BvPKV"1H~mMBTZ4>TO+z|/ X-Hue: red X-Attribution: GM Date: Sat, 09 Jul 2011 01:51:06 -0400 In-Reply-To: (Stefan Monnier's message of "Wed, 28 Oct 2009 20:37:53 -0400") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 4819-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) I don't see a need to keep open this particular report, which was marked "wontfix" some time ago. ------------=_1310190722-18897-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by emacsbugs.donarmstrong.com; 28 Oct 2009 00:28:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=AWL,MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9S0Smlv018665 for ; Tue, 27 Oct 2009 17:28:50 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N2wP9-0004tq-UT for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 20:28:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N2wP3-0004nd-Dn for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 20:28:45 -0400 Received: from [199.232.76.173] (port=51311 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N2wP3-0004nV-BR for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 20:28:41 -0400 Received: from mail-yw0-f194.google.com ([209.85.211.194]:33185) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N2wP3-0007kG-14 for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 20:28:41 -0400 Received: by ywh32 with SMTP id 32so241487ywh.14 for ; Tue, 27 Oct 2009 17:28:40 -0700 (PDT) MIME-Version: 1.0 Sender: stan@derbycityprints.com Received: by 10.150.44.2 with SMTP id r2mr27843987ybr.77.1256689720441; Tue, 27 Oct 2009 17:28:40 -0700 (PDT) Date: Tue, 27 Oct 2009 20:28:40 -0400 X-Google-Sender-Auth: 2daeca6eea06147a Message-ID: Subject: file-truename's undocumented behavior From: MON KEY To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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) ------------=_1310190722-18897-1--