GNU bug report logs - #61926
29.0.60; [PATCH] Make tramp-remote-path behave like exec-path

Previous Next

To reply to this bug, email your comments to 61926 AT debbugs.gnu.org.

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

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

From: João Távora <joaotavora <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.60; [PATCH] Make tramp-remote-path behave like exec-path
Date: Fri, 03 Mar 2023 00:19:50 +0000

Hi maintainers, Michael,

This started in bug#61748.  There we discovered that while something
like this works and will correctly find '/home/user/bin/myscript'

    ~/Source/Emacs/emacs/src/emacs -Q --batch                \
    -l tramp                                                 \
    --eval '(add-to-list (quote tramp-remote-path) "~/bin")' \
    $REMOTE_FILE                                             \
    --eval '(message "%s" (executable-find "myscript" t))'

This subtly different incantation will _not_ work:

    ~/Source/Emacs/emacs/src/emacs -Q --batch                \
    -l tramp                                                 \
    $REMOTE_FILE                                             \
    --eval '(add-to-list (quote tramp-remote-path) "~/bin")' \
    --eval '(message "%s" (executable-find "myscript" t))'

This is because of a caching behaviour in tramp-get-remote-path.

The patch after my sig solves the problem: the above two incantations
produce the same value.  It will prevent confusion among users (as I
was) about the what seemed like unstable behaviour from executble-find
and program invocation.

Very few Emacs variables, if any, require a separate command (here M-x
tramp-cleanup-all-connections) to be issued after the variables value is
set.  This variable needn't belong to that group.  

There is a discussion about this caching somewhat deep in the Tramp
manual.  But I think it would be much nicer if simple things like this
worked out of the box, allowing users to experiment with value for
`tramp-remote-path' via M-: (setq ... ) or some other variable-setting
method, until they get it right.

Changing this variable's value doesn't alter the remote value of the
PATH environment variable, much like changing exec-path locally doesn't
change the local PATH environment variable.

João

commit c9d577b9ede6192af6db47442ab9709127e39fb2
Author: João Távora <joaotavora <at> gmail.com>
Date:   Wed Mar 1 11:03:23 2023 +0000

    Tramp: flush configuration if tramp-remote-path changed
    
    * lisp/net/tramp-sh.el (tramp-last-used-remote-path): New variable.
    (tramp-get-remote-path): Use it to decide to flush.

diff --git a/lisp/net/tramp-sh.el b/lisp/net/tramp-sh.el
index ec8437176db..29d2dda6829 100644
--- a/lisp/net/tramp-sh.el
+++ b/lisp/net/tramp-sh.el
@@ -5571,10 +5571,18 @@ tramp-check-remote-uname
   "Check whether REGEXP matches the connection property \"uname\"."
   (string-match-p regexp (tramp-get-connection-property vec "uname" "")))
 
+(defvar tramp-last-used-remote-path nil)
+
 (defun tramp-get-remote-path (vec)
   "Compile list of remote directories for PATH.
 Nonexistent directories are removed from spec."
   (with-current-buffer (tramp-get-connection-buffer vec)
+    (when (not (equal tramp-last-used-remote-path tramp-remote-path))
+      ;; If user has tweaked `tramp-remote-path', flush any caches
+      ;; bug#61748.
+      (dolist (v (list vec (tramp-get-process vec)))
+        (tramp-flush-connection-property v "remote-path")))
+    (setq tramp-last-used-remote-path tramp-remote-path)
     ;; Expand connection-local variables.
     (tramp-set-connection-local-variables vec)
     (with-tramp-connection-property

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: michael.albinus <at> gmx.de, 61926 <at> debbugs.gnu.org
Subject: Re: bug#61926: 29.0.60;
 [PATCH] Make tramp-remote-path behave like exec-path
Date: Fri, 03 Mar 2023 09:23:58 +0200

> Cc: michael.albinus <at> gmx.de
> From: João Távora <joaotavora <at> gmail.com>
> Date: Fri, 03 Mar 2023 00:19:50 +0000
> 
> Very few Emacs variables, if any, require a separate command (here M-x
> tramp-cleanup-all-connections) to be issued after the variables value is
> set.  This variable needn't belong to that group.  
> 
> There is a discussion about this caching somewhat deep in the Tramp
> manual.  But I think it would be much nicer if simple things like this
> worked out of the box, allowing users to experiment with value for
> `tramp-remote-path' via M-: (setq ... ) or some other variable-setting
> method, until they get it right.
> 
> Changing this variable's value doesn't alter the remote value of the
> PATH environment variable, much like changing exec-path locally doesn't
> change the local PATH environment variable.

We nowadays have variable-watching feature in Emacs, see
add-variable-watcher.  Could that facility be used in this case to
allow a more elegant solution?

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

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael.albinus <at> gmx.de, 61926 <at> debbugs.gnu.org
Subject: Re: bug#61926: 29.0.60;
 [PATCH] Make tramp-remote-path behave like exec-path
Date: Fri, 3 Mar 2023 16:20:29 +0000

On Fri, Mar 3, 2023 at 7:24 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> We nowadays have variable-watching feature in Emacs, see
> add-variable-watcher.  Could that facility be used in this case to
> allow a more elegant solution?

Yes, good idea.  But only if we have access to the cache
locations that we have to flush. These would be the "remote-path"
properties of every Tramp connection, and I _think_ there's
an accessor for that, but I have to check.

Which reminds me, that patch I sent has a big thinko :-)

If you re-set tramp-remote-path you get flushing for the
next call to tramp-get-remote-path, which will be for a given
connection.  At that moment you forget changes by setting
tramp-last-used-remote-path so and you will fail to flush for
the next connection.

Not hard to fix, we just have to make sure to flush _all_
connections when we detect the change, however we detect it.

João

Previous Next

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