GNU bug report logs - #49009
27.1.90; files loaded with -l flag does not use file-truename as required by eval-after-load

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 49009 in the body.
You can then email your comments to 49009 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: ctarbide <at> tuta.io
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1.90; files loaded with -l flag does not use file-truename as
 required by eval-after-load
Date: Sun, 13 Jun 2021 23:56:35 +0200 (CEST)

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

Consider:

emacs -nw -Q -batch -L "`pwd`" -l test.el

if the test.el file above is in a non-true path, e.g. a parent dir is a
symlink, and test.el has an eval-after-load for itself, the eval-after-load
form will not be evaluated, the reason is that startup.el does not usefile-truename while loading file, the change below solved the issue:

-  (file-ex (expand-file-name file)))
+  (file-ex (file-truename (expand-file-name file))))

http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/startup.el#n2503

[Message part 2 (text/html, inline)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: ctarbide <at> tuta.io
Cc: 49009 <at> debbugs.gnu.org
Subject: Re: bug#49009: 27.1.90; files loaded with -l flag does not use
 file-truename as required by eval-after-load
Date: Mon, 14 Jun 2021 15:38:12 +0200

ctarbide <at> tuta.io writes:

> if the test.el file above is in a non-true path, e.g. a parent dir is a
> symlink, and test.el has an eval-after-load for itself, the eval-after-load
> form will not be evaluated, the reason is that startup.el does not use
> file-truename while loading file, the change below solved the issue:
>
> -  (file-ex (expand-file-name file)))
> +  (file-ex (file-truename (expand-file-name file))))

There's two of these, so here's the proposed patch, I think.

This seems reasonable to me -- anybody else have any comments?  I was
wondering whether there may be edge cases where this may lead to
unintended consequences...

diff --git a/lisp/startup.el b/lisp/startup.el
index ac319612e8..456c01efd1 100644
--- a/lisp/startup.el
+++ b/lisp/startup.el
@@ -2500,7 +2500,7 @@ command-line-1
                                    (or argval (pop command-line-args-left))))
                             ;; Take file from default dir if it exists there;
                             ;; otherwise let `load' search for it.
-                            (file-ex (expand-file-name file)))
+                            (file-ex (file-truename (expand-file-name file))))
                        (when (file-regular-p file-ex)
                          (setq file file-ex))
                        (load file nil t)))
@@ -2511,7 +2511,7 @@ command-line-1
                      (let* ((file (command-line-normalize-file-name
                                    (or argval (pop command-line-args-left))))
                             ;; Take file from default dir.
-                            (file-ex (expand-file-name file)))
+                            (file-ex (file-truename (expand-file-name file))))
                        (load file-ex nil t t)))
 
                     ((equal argi "-insert")


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: ctarbide <at> tuta.io
Cc: 49009 <at> debbugs.gnu.org
Subject: Re: bug#49009: 27.1.90; files loaded with -l flag does not use
 file-truename as required by eval-after-load
Date: Sat, 19 Jun 2021 15:59:09 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> This seems reasonable to me -- anybody else have any comments?  I was
> wondering whether there may be edge cases where this may lead to
> unintended consequences...

There were no comments in five days, so I've pushed the patch to Emacs
28.  I couldn't see any adverse effects, but if this breaks something
for somebody, it should be reverted.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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