GNU bug report logs - #65551
29.1; Eshell on MS-Windows using plink: 'plink' is not recognized as an internal or external command...

Previous Next

To reply to this bug, email your comments to 65551 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: Jordan Wilson <jordan.t.wilson <at> gmx.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.1; Eshell on MS-Windows using plink: 'plink' is not recognized
 as an internal or external command...
Date: Sat, 26 Aug 2023 15:11:53 +0100

Hi all,

I've found a bug in Eshell on MS-Windows on 29.1. This is a regression
from 28.2. When connected to a remote machine using putty's "plink",
using any commands on the remote machine (e.g. not built-in to eshell)
prints this error in the eshell buffer (details replaced):

plink -l username -ssh -t example.com " env 'TERM=dumb'
'PROMPT_COMMAND=' 'PS1=#$ ' /bin/sh -i " ** exit || exit
'plink' is not recognised as an internal or external command, operable
program or batch file.

and the following in the minibuffer:
Tramp failed to connect.  If this happens repeatedly, try
    "M-x tramp-cleanup-this-connection"

An keyboard input after this causes the eshell buffer to be killed, and the
"Tramp failed to connect..." message to also be inserted into the next buffer.

Recipe, starting from "emacs -Q":
1) open eshell
2) connect to a remote host using plink
- cd /plink:username <at> example.com:/home/username/
3) ./test.sh (executable script)
or...
3) *ls
or...
3) (any remote command not built-in into Emacs)

Below is the backtrace produced from this (using
`toggle-debug-on-error') again with details replaced.

Thanks,
Jordan.

Debugger entered--Lisp error: (file-error "Tramp failed to connect.  If this happens repeated...")
  signal(file-error ("Tramp failed to connect.  If this happens repeated..."))
  tramp-error(nil file-error "Tramp failed to connect.  If this happens repeated...")
  tramp-signal-hook-function(file-error ("Tramp failed to connect.  If this happens repeated..."))
  signal(file-error ("Tramp failed to connect.  If this happens repeated..."))
  tramp-maybe-open-connection((tramp-file-name #("plink" 0 5 (escaped t)) #("username" 0 5 (escaped t)) nil #("example.com" 0 18 (escaped t)) nil nil nil))
  tramp-send-command((tramp-file-name #("plink" 0 5 (escaped t)) #("username" 0 5 (escaped t)) nil #("example.com" 0 18 (escaped t)) nil nil nil) "echo $$ 2>/dev/null; echo tramp_exit_status $?")
  tramp-send-command-and-check((tramp-file-name #("plink" 0 5 (escaped t)) #("username" 0 5 (escaped t)) nil #("example.com" 0 18 (escaped t)) nil nil nil) "echo $$")
  tramp-barf-unless-okay((tramp-file-name #("plink" 0 5 (escaped t)) #("username" 0 5 (escaped t)) nil #("example.com" 0 18 (escaped t)) nil nil nil) "echo $$" "`%s' returns with error" "echo $$")
  tramp-send-command-and-read((tramp-file-name #("plink" 0 5 (escaped t)) #("username" 0 5 (escaped t)) nil #("example.com" 0 18 (escaped t)) nil nil nil) "echo $$")
  tramp-sh-handle-make-process(:name "test.sh" :buffer #<killed buffer> :command ("/home/username/test.sh") :filter eshell-output-filter :sentinel eshell-sentinel :connection-type nil :stderr nil :file-handler t)
  tramp-sh-file-name-handler(make-process :name "test.sh" :buffer #<killed buffer> :command ("/home/username/test.sh") :filter eshell-output-filter :sentinel eshell-sentinel :connection-type nil :stderr nil :file-handler t)
  apply(tramp-sh-file-name-handler make-process (:name "test.sh" :buffer #<killed buffer> :command ("/home/username/test.sh") :filter eshell-output-filter :sentinel eshell-sentinel :connection-type nil :stderr nil :file-handler t))
  tramp-file-name-handler(make-process :name "test.sh" :buffer #<killed buffer> :command ("/home/username/test.sh") :filter eshell-output-filter :sentinel eshell-sentinel :connection-type nil :stderr nil :file-handler t)
  eshell-gather-process-output("/plink:username <at> example.com:/home/username/test.s..." nil)
  eshell-external-command("./test.sh" nil)
  eshell-plain-command("./test.sh" nil)
  eshell-named-command("./test.sh")
  eval((eshell-named-command '"./test.sh"))
  eshell-do-eval((eshell-named-command '"./test.sh") nil)
  eshell-do-eval((prog1 (eshell-named-command '"./test.sh") (mapc #'funcall eshell-this-command-hook)) nil)
  (condition-case err (eshell-do-eval '(prog1 (eshell-named-command '"./test.sh") (mapc #'funcall eshell-this-command-hook)) nil) ((debug error) (mapc #'funcall eshell-this-command-hook) (eshell-errorn (error-message-string err)) (eshell-close-handles 1)))
  eval((condition-case err (eshell-do-eval '(prog1 (eshell-named-command '"./test.sh") (mapc #'funcall eshell-this-command-hook)) nil) ((debug error) (mapc #'funcall eshell-this-command-hook) (eshell-errorn (error-message-string err)) (eshell-close-handles 1))))
  eshell-do-eval((condition-case err (eshell-do-eval '(prog1 (eshell-named-command '"./test.sh") (mapc #'funcall eshell-this-command-hook)) nil) ((debug error) (mapc #'funcall eshell-this-command-hook) (eshell-errorn (error-message-string err)) (eshell-close-handles 1))) nil)
  #f(compiled-function () #<bytecode -0x12092870cc88ed70>)()
  funcall(#f(compiled-function () #<bytecode -0x12092870cc88ed70>))
  (let ((eshell-this-command-hook '(ignore))) (funcall '#f(compiled-function () #<bytecode -0x12092870cc88ed70>)))
  eval((let ((eshell-this-command-hook '(ignore))) (funcall '#f(compiled-function () #<bytecode -0x12092870cc88ed70>))))
  eshell-do-eval((let ((eshell-this-command-hook '(ignore))) (condition-case err (eshell-do-eval '(prog1 (eshell-named-command '"./test.sh") (mapc #'funcall eshell-this-command-hook)) nil) ((debug error) (mapc #'funcall eshell-this-command-hook) (eshell-errorn (error-message-string err)) (eshell-close-handles 1)))) nil)
  eshell-do-eval((progn (let ((eshell-this-command-hook '(ignore))) (condition-case err (eshell-do-eval '(prog1 (eshell-named-command ...) (mapc ... eshell-this-command-hook)) nil) ((debug error) (mapc #'funcall eshell-this-command-hook) (eshell-errorn (error-message-string err)) (eshell-close-handles 1))))) nil)
  (catch 'top-level (eshell-do-eval '(progn (let ((eshell-this-command-hook '...)) (condition-case err (eshell-do-eval '... nil) ((debug error) (mapc ... eshell-this-command-hook) (eshell-errorn ...) (eshell-close-handles 1))))) nil))
  eval((catch 'top-level (eshell-do-eval '(progn (let ((eshell-this-command-hook ...)) (condition-case err (eshell-do-eval ... nil) (... ... ... ...)))) nil)))
  eshell-do-eval((catch 'top-level (eshell-do-eval '(progn (let ((eshell-this-command-hook ...)) (condition-case err (eshell-do-eval ... nil) (... ... ... ...)))) nil)) nil)
  eshell-do-eval((progn 'nil (catch 'top-level (eshell-do-eval '(progn (let (...) (condition-case err ... ...))) nil)) (run-hooks 'eshell-post-command-hook)) nil)
  #f(compiled-function () #<bytecode -0x12092870cc88ed70>)()
  funcall(#f(compiled-function () #<bytecode -0x12092870cc88ed70>))
  (let ((eshell-current-handles '[nil (t . 1) (t . 1)]) (eshell-current-subjob-p 'nil)) (funcall '#f(compiled-function () #<bytecode -0x12092870cc88ed70>)))
  eval((let ((eshell-current-handles '[nil (t . 1) (t . 1)]) (eshell-current-subjob-p 'nil)) (funcall '#f(compiled-function () #<bytecode -0x12092870cc88ed70>))))
  eshell-do-eval((let ((eshell-current-handles '[nil (t . 1) (t . 1)]) eshell-current-subjob-p) (progn 'nil (catch 'top-level (eshell-do-eval '(progn (let ... ...)) nil)) (run-hooks 'eshell-post-command-hook))))
  eshell-resume-eval()
  eshell-eval-command((let ((eshell-current-handles '[nil (t . 1) (t . 1)]) eshell-current-subjob-p) (progn 'nil (catch 'top-level (eshell-do-eval '(progn (let ... ...)) nil)) (run-hooks 'eshell-post-command-hook))) "./test.sh ")
  eshell-send-input(nil)
  funcall-interactively(eshell-send-input nil)
  #<subr call-interactively>(eshell-send-input nil nil)
  call-interactively <at> ido-cr+-record-current-command(#<subr call-interactively> eshell-send-input nil nil)
  apply(call-interactively <at> ido-cr+-record-current-command #<subr call-interactively> (eshell-send-input nil nil))
  call-interactively(eshell-send-input nil nil)
  command-execute(eshell-send-input)


In GNU Emacs 29.1 (build 2, x86_64-w64-mingw32) of 2023-08-02 built on
 AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Home (v10.0.2009.19045.3324)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation=aot
 --without-compress-install --with-tree-sitter CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

Important settings:
  value of $LANG: ENG
  locale-coding-system: cp1252

Major mode: Messages

Minor modes in effect:
  immortal-scratch-mode: t
  emms-mode-line-mode: t
  emms-playing-time-display-mode: t
  emms-playing-time-mode: t
  shell-dirtrack-mode: t
  recentf-mode: t
  global-anzu-mode: t
  anzu-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  winner-mode: t
  delete-selection-mode: t
  cua-mode: t
  ido-everywhere: t
  pdf-occur-global-minor-mode: t
  windmove-mode: t
  server-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: (only . t)
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t


--
Jordan Wilson
    Sent from Gnus v5.13, GNU Emacs 29.1 on WINDOWS-NT

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jordan Wilson <jordan.t.wilson <at> gmx.com>
Cc: 65551 <at> debbugs.gnu.org
Subject: Re: bug#65551: 29.1;
 Eshell on MS-Windows using plink: 'plink' is not recognized as an
 internal or external command...
Date: Sat, 26 Aug 2023 17:42:15 +0300

> From: Jordan Wilson <jordan.t.wilson <at> gmx.com>
> Date: Sat, 26 Aug 2023 15:11:53 +0100
> 
> I've found a bug in Eshell on MS-Windows on 29.1. This is a regression
> from 28.2. When connected to a remote machine using putty's "plink",
> using any commands on the remote machine (e.g. not built-in to eshell)
> prints this error in the eshell buffer (details replaced):
> 
> plink -l username -ssh -t example.com " env 'TERM=dumb'
> 'PROMPT_COMMAND=' 'PS1=#$ ' /bin/sh -i " ** exit || exit
> 'plink' is not recognised as an internal or external command, operable
> program or batch file.

Is plink on PATH on that Windows system?

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

From: Jordan Wilson <jordan.t.wilson <at> gmx.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 65551 <at> debbugs.gnu.org
Subject: Re: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is
 not recognized as an internal or external command...
Date: Sat, 26 Aug 2023 15:48:07 +0100

(oops, sorry Eli, didn't wide reply)

On 2023-08-26 (Sat) at 17:42 (+0300), Eli Zaretskii <eliz <at> gnu.org> wrote:
> Is plink on PATH on that Windows system?

Yes, it's on the Windows' machine I'm connecting from. Eshell
successfully connects to the GNU/Linux machine using plink, but in the
cases described it produces the error. I can use eshell built-in
commands (like `ls' and `pwd') fine on the remote machine, but external
commands on it produces the error.

--
Jordan Wilson
    Sent from Gnus v5.13, GNU Emacs 29.1 on WINDOWS-NT

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jordan Wilson <jordan.t.wilson <at> gmx.com>
Cc: 65551 <at> debbugs.gnu.org
Subject: Re: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is
 not recognized as an internal or external command...
Date: Sat, 26 Aug 2023 18:12:29 +0300

> From: Jordan Wilson <jordan.t.wilson <at> gmx.com>
> Cc: 65551 <at> debbugs.gnu.org
> Date: Sat, 26 Aug 2023 15:48:07 +0100
> 
> (oops, sorry Eli, didn't wide reply)
> 
> On 2023-08-26 (Sat) at 17:42 (+0300), Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Is plink on PATH on that Windows system?
> 
> Yes, it's on the Windows' machine I'm connecting from. Eshell
> successfully connects to the GNU/Linux machine using plink, but in the
> cases described it produces the error. I can use eshell built-in
> commands (like `ls' and `pwd') fine on the remote machine, but external
> commands on it produces the error.

Then I don't think I understand the backtrace you posted.  It seems to
indicate that Trump signals a "failed to connect" error, but the error
message you cited, i.e.

  'plink' is not recognised as an internal or external command, operable
  program or batch file.

is the message shown by the Windows cmd.exe shell, it is not a Tramp
error message.  So it looks like the backtrace does not really show
the relevant error?  Could you perhaps produce a backtrace that is
more relevant to the problem you are having?

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Jordan Wilson <jordan.t.wilson <at> gmx.com>, 65551 <at> debbugs.gnu.org,
 michael.albinus <at> gmx.de
Subject: Re: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is not
 recognized as an internal or external command...
Date: Sat, 26 Aug 2023 12:16:12 -0700

On 8/26/2023 7:11 AM, Jordan Wilson wrote:
> I've found a bug in Eshell on MS-Windows on 29.1. This is a regression
> from 28.2. When connected to a remote machine using putty's "plink",
> using any commands on the remote machine (e.g. not built-in to eshell)
> prints this error in the eshell buffer (details replaced):

Thanks for reporting this. I can reproduce this issue. Does evaluating 
the following work?

  (setf (alist-get 'tramp-login-program
                   (alist-get "plink" tramp-methods nil nil #'equal))
        (list (concat "\"" (executable-find "plink") "\"")))

If so, I think I've identified the bug: in 
'eshell-gather-process-output', we set the 'process-environment' to 
Eshell's environment variables. In a remote directory, this includes the 
remote PATH. However, that confuses Tramp, which uses that remote PATH 
to look for the local "plink.exe".

Michael, what would be the best way to handle this? In Eshell, I want to 
be able to call 'make-process' to start a remote process using the local 
system's default 'process-environment', but for the remote process to 
see Eshell's modified environment variables. I see that there's 
'tramp-remote-process-environment', but I'm not sure that's the right 
thing for me to use. Do you have any ideas?

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

From: Jordan Wilson <jordan.t.wilson <at> gmx.com>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 65551 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is
 not recognized as an internal or external command...
Date: Sat, 26 Aug 2023 22:28:56 +0100

Hi Jim,

On 2023-08-26 (Sat) at 12:16 (-0700), Jim Porter <jporterbugs <at> gmail.com> wrote:
> Thanks for reporting this. I can reproduce this issue. Does evaluating the
> following work?
>
>   (setf (alist-get 'tramp-login-program
>                    (alist-get "plink" tramp-methods nil nil #'equal))
>         (list (concat "\"" (executable-find "plink") "\"")))
>
> If so, I think I've identified the bug: in 'eshell-gather-process-output', we
> set the 'process-environment' to Eshell's environment variables. In a remote
> directory, this includes the remote PATH. However, that confuses Tramp, which
> uses that remote PATH to look for the local "plink.exe".

I can confirm that snippet does resolve the problem.

--
Jordan Wilson
    Sent from Gnus v5.13, GNU Emacs 29.1 on WINDOWS-NT

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Jordan Wilson <jordan.t.wilson <at> gmx.com>
Cc: 65551 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is not
 recognized as an internal or external command...
Date: Sat, 26 Aug 2023 23:30:05 -0700

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

On 8/26/2023 2:28 PM, Jordan Wilson wrote:
> Hi Jim,
> 
> On 2023-08-26 (Sat) at 12:16 (-0700), Jim Porter <jporterbugs <at> gmail.com> wrote:
>> Thanks for reporting this. I can reproduce this issue. Does evaluating the
>> following work?
>>
>>    (setf (alist-get 'tramp-login-program
>>                     (alist-get "plink" tramp-methods nil nil #'equal))
>>          (list (concat "\"" (executable-find "plink") "\"")))
>>
>> If so, I think I've identified the bug: in 'eshell-gather-process-output', we
>> set the 'process-environment' to Eshell's environment variables. In a remote
>> directory, this includes the remote PATH. However, that confuses Tramp, which
>> uses that remote PATH to look for the local "plink.exe".
> 
> I can confirm that snippet does resolve the problem.

Thanks for checking. That's probably the best way to get things working 
for now, but I'll make sure to get a fix for this in for Emacs 29.2. In 
the meantime, here's a regression test that we should be able to use to 
verify the fix once we have it.

[remote-path-test.patch (text/plain, attachment)]

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jordan Wilson <jordan.t.wilson <at> gmx.com>
Cc: 65551 <at> debbugs.gnu.org, Jim Porter <jporterbugs <at> gmail.com>
Subject: Re: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is
 not recognized as an internal or external command...
Date: Sun, 27 Aug 2023 19:50:44 +0200

Jordan Wilson <jordan.t.wilson <at> gmx.com> writes:

> Hi all,

Hi Jordan & Jim,

> I've found a bug in Eshell on MS-Windows on 29.1. This is a regression
> from 28.2. When connected to a remote machine using putty's "plink",
> using any commands on the remote machine (e.g. not built-in to eshell)
> prints this error in the eshell buffer (details replaced):
>
> plink -l username -ssh -t example.com " env 'TERM=dumb'
> 'PROMPT_COMMAND=' 'PS1=#$ ' /bin/sh -i " ** exit || exit
> 'plink' is not recognised as an internal or external command, operable
> program or batch file.
>
> Recipe, starting from "emacs -Q":
> 1) open eshell
> 2) connect to a remote host using plink
> - cd /plink:username <at> example.com:/home/username/
> 3) ./test.sh (executable script)
> or...
> 3) *ls
> or...
> 3) (any remote command not built-in into Emacs)
>
> Below is the backtrace produced from this (using
> `toggle-debug-on-error') again with details replaced.

First I try to understand the scenario Eshell is using. If Eshell has
changed to a remote directory, and a command like "./test.sh" is called,
I would expect a synchronous process. But this doesn't seem to be the case:

>   tramp-file-name-handler(make-process :name "test.sh" :buffer #<killed buffer> :command ("/home/username/test.sh") :filter eshell-output-filter :sentinel eshell-sentinel :connection-type nil :stderr nil :file-handler t)
>   eshell-gather-process-output("/plink:username <at> example.com:/home/username/test.s..." nil)
>   eshell-external-command("./test.sh" nil)

`make-process' is called, an asynchronous process. Is this intended? Has
this been changed since Emacs 28?

Second, I've played a little bit on MS Windows. I haven't installed
Emacs 29 there, just an Emacs git master checkout. And plink is not in
the PATH of my MINGW64 bash shell, so I'm using sshx. But everything
works under this constellation:

--8<---------------cut here---------------start------------->8---
Welcome to the Emacs shell

~ $ *hostname
win10
~ $ *uname -sr
MINGW64_NT-10.0-19045 3.2.0-340.x86_64
~ $ cd /sshx:detlef.fritz.box:
/sshx:detlef.fritz.box:~ $ *hostname
detlef
/sshx:detlef.fritz.box:~ $ *uname -sr
Linux 6.2.0-27-generic
/sshx:detlef.fritz.box:~ $ which hostname
/sshx:detlef.fritz.box://usr/bin/hostname
/sshx:detlef.fritz.box:~ $ *which hostname
/usr/bin/hostname
/sshx:detlef.fritz.box:~ $
--8<---------------cut here---------------end--------------->8---

> Thanks,
> Jordan.

Best regards, Michael.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Jordan Wilson <jordan.t.wilson <at> gmx.com>, 65551 <at> debbugs.gnu.org
Subject: Re: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is
 not recognized as an internal or external command...
Date: Sun, 27 Aug 2023 19:55:42 +0200

Jim Porter <jporterbugs <at> gmail.com> writes:

Hi Jim,

> Thanks for reporting this. I can reproduce this issue. Does evaluating
> the following work?
>
>   (setf (alist-get 'tramp-login-program
>                    (alist-get "plink" tramp-methods nil nil #'equal))
>         (list (concat "\"" (executable-find "plink") "\"")))

This workaround might help in the given situation, but it won't work in
general. The user could apply a multi-hop file name, with plink being
the method of another hop.

Best regards, Michael.

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>,
 Jordan Wilson <jordan.t.wilson <at> gmx.com>
Cc: 65551 <at> debbugs.gnu.org
Subject: Re: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is not
 recognized as an internal or external command...
Date: Sun, 27 Aug 2023 11:48:36 -0700

On 8/27/2023 10:50 AM, Michael Albinus wrote:
> First I try to understand the scenario Eshell is using. If Eshell has
> changed to a remote directory, and a command like "./test.sh" is called,
> I would expect a synchronous process. But this doesn't seem to be the case:
> 
>>    tramp-file-name-handler(make-process :name "test.sh" :buffer #<killed buffer> :command ("/home/username/test.sh") :filter eshell-output-filter :sentinel eshell-sentinel :connection-type nil :stderr nil :file-handler t)
>>    eshell-gather-process-output("/plink:username <at> example.com:/home/username/test.s..." nil)
>>    eshell-external-command("./test.sh" nil)
> 
> `make-process' is called, an asynchronous process. Is this intended? Has
> this been changed since Emacs 28?

Yeah, that's intended. A couple of things did change in Emacs 29, but 
Eshell has always used an asynchronous process here. The goal is for the 
process to be only partially synchronous: Eshell will wait until the 
process is done before proceeding (e.g. to emit the next prompt), but it 
also wants to be async so that you can do other things in Emacs while 
waiting for the process to complete.

> Second, I've played a little bit on MS Windows. I haven't installed
> Emacs 29 there, just an Emacs git master checkout. And plink is not in
> the PATH of my MINGW64 bash shell, so I'm using sshx. But everything
> works under this constellation:

I'm using sshx locally to test this, and can reproduce the issue. Maybe 
your MINGW64 configuration is smoothing over the bug for you. When I 
tested this, I started from the MS-Windows "cmd.exe" and ran "emacs -Q", 
with "ssh.exe" in my PATH.

In Emacs 28, this worked fine, but it regressed in 29. I believe this is 
due to commit cee1cbfd54375cdece23d4741ced6b0c7091f6d9, which changes 
how Eshell manages its PATH env var.

I think what Eshell would want here is to set its environment variables 
*only* for the subprocess it creates via 'make-process'. For local 
subprocesses, I don't think we need to do anything fancy, but for the 
remote case, we'd need a way to say "use the original 
process-environment for all the Tramp code, but use this new 
process-environment for the actual subprocess". Maybe there's already a 
way to do this, or maybe we need to add some new powers to 
'make-process' or something...

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Jordan Wilson <jordan.t.wilson <at> gmx.com>, 65551 <at> debbugs.gnu.org
Subject: Re: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is
 not recognized as an internal or external command...
Date: Mon, 28 Aug 2023 12:27:59 +0200

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

Jim Porter <jporterbugs <at> gmail.com> writes:

Hi Jim,

>> Second, I've played a little bit on MS Windows. I haven't installed
>> Emacs 29 there, just an Emacs git master checkout. And plink is not in
>> the PATH of my MINGW64 bash shell, so I'm using sshx. But everything
>> works under this constellation:
>
> I'm using sshx locally to test this, and can reproduce the
> issue. Maybe your MINGW64 configuration is smoothing over the bug for
> you. When I tested this, I started from the MS-Windows "cmd.exe" and
> ran "emacs -Q", with "ssh.exe" in my PATH.

Yes, with this scenario I see the problem as well.

> In Emacs 28, this worked fine, but it regressed in 29. I believe this
> is due to commit cee1cbfd54375cdece23d4741ced6b0c7091f6d9, which
> changes how Eshell manages its PATH env var.
>
> I think what Eshell would want here is to set its environment
> variables *only* for the subprocess it creates via 'make-process'. For
> local subprocesses, I don't think we need to do anything fancy, but
> for the remote case, we'd need a way to say "use the original
> process-environment for all the Tramp code, but use this new
> process-environment for the actual subprocess". Maybe there's already
> a way to do this, or maybe we need to add some new powers to
> 'make-process' or something...

AFAICS, the problem is in eshell-environment-variables, which sets PATH
to the remote path. There are good reasons that Tramp doesn't handle the
PATH environment variable, but uses its own tramp-remote-path variable.

I've applied the following sledge-hammer patch, which cures the problem
for me. But I'm pretty sure there are better ways in Eshell to fix this.

Best regards, Michael.

[Message part 2 (text/x-patch, attachment)]

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Jordan Wilson <jordan.t.wilson <at> gmx.com>, 65551 <at> debbugs.gnu.org
Subject: Re: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is not
 recognized as an internal or external command...
Date: Mon, 28 Aug 2023 09:29:50 -0700

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

On 8/28/2023 3:27 AM, Michael Albinus wrote:
> I've applied the following sledge-hammer patch, which cures the problem
> for me. But I'm pretty sure there are better ways in Eshell to fix this.

How about something like this? It's a little less invasive (but no less 
of a hack).

I'll have to think about this more generally though, since I think 
Eshell should be a lot more precise about how it handles environment 
variables on remote hosts in general. Maybe we even want each host to 
have its own distinct set of env vars. That would probably be safer...

[0001-Fix-remote-path-setting-in-Eshell.patch (text/plain, attachment)]

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Jordan Wilson <jordan.t.wilson <at> gmx.com>, 65551 <at> debbugs.gnu.org
Subject: Re: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is not
 recognized as an internal or external command...
Date: Mon, 28 Aug 2023 09:47:47 -0700

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

On 8/28/2023 9:29 AM, Jim Porter wrote:
> On 8/28/2023 3:27 AM, Michael Albinus wrote:
>> I've applied the following sledge-hammer patch, which cures the problem
>> for me. But I'm pretty sure there are better ways in Eshell to fix this.
> 
> How about something like this? It's a little less invasive (but no less 
> of a hack).

Oops, something more like this (let-binding 'tramp-remote-path').

[0001-Fix-remote-path-setting-in-Eshell.patch (text/plain, attachment)]

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Jordan Wilson <jordan.t.wilson <at> gmx.com>, 65551 <at> debbugs.gnu.org
Subject: Re: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is not
 recognized as an internal or external command...
Date: Mon, 28 Aug 2023 09:53:11 -0700

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

On 8/28/2023 9:47 AM, Jim Porter wrote:
> On 8/28/2023 9:29 AM, Jim Porter wrote:
>> On 8/28/2023 3:27 AM, Michael Albinus wrote:
>>> I've applied the following sledge-hammer patch, which cures the problem
>>> for me. But I'm pretty sure there are better ways in Eshell to fix this.
>>
>> How about something like this? It's a little less invasive (but no 
>> less of a hack).
> 
> Oops, something more like this (let-binding 'tramp-remote-path').

Uh... the third time's the charm I guess? (Sorry for the extra emails.)

[0001-Fix-remote-path-setting-in-Eshell.patch (text/plain, attachment)]

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Jordan Wilson <jordan.t.wilson <at> gmx.com>, 65551 <at> debbugs.gnu.org
Subject: Re: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is
 not recognized as an internal or external command...
Date: Mon, 28 Aug 2023 19:33:30 +0200

Jim Porter <jporterbugs <at> gmail.com> writes:

Hi Jim,

> On 8/28/2023 9:29 AM, Jim Porter wrote:
>> On 8/28/2023 3:27 AM, Michael Albinus wrote:
>>> I've applied the following sledge-hammer patch, which cures the problem
>>> for me. But I'm pretty sure there are better ways in Eshell to fix this.
>> How about something like this? It's a little less invasive (but no
>> less of a hack).
>
> Oops, something more like this (let-binding 'tramp-remote-path').

Might work. But well, it is Tramp. Everything is more complex.

tramp-remote-path is just a template, It is taken the very first time
you connect to a remote host in order to determine proper PATH
settings. The result is cached in the connection property "remote-path".

Every new process for that remote host (like returned by make-process)
checks first, whether this connection property exists, and uses it. Only
if the connection property doesn't exist, it is recomputed starting with
tramp-remote-path.

So usually, you don't have to do anything wrt PATH. That's why my
sledge-hammer patch works.

If a user changes PATH for a remote connection in eshell (I don't recall
how, but I'm sure it is possible in Eshell), you just have to change the
respective connection property "remote-path" in Tramp.
See (info "(tramp) Predefined connection information")

There is an exception: If a user has the symbol tramp-own-remote-path
in tramp-remote-path, the cached value is not used for a new process,
and PATH is recomputed based on tramp-remote-path.

Writing this, it sounds to me too complex. OTOH, no other package has
tried yet to play with the remote PATH. There are bug reports by users
who request a simplification (bug#61926, bug#62326). Perhaps it is time
to redesign the machinery in Tramp.

Best regards, Michael.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Jordan Wilson <jordan.t.wilson <at> gmx.com>, 65551 <at> debbugs.gnu.org
Subject: Re: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is
 not recognized as an internal or external command...
Date: Mon, 28 Aug 2023 19:40:19 +0200

Jim Porter <jporterbugs <at> gmail.com> writes:

Hi Jim,

> Uh... the third time's the charm I guess? (Sorry for the extra emails.)

Take your time. Tomorrow, my grand-son will arrive, staying for 10 days
or so (remainder of school holidays). Be prepared that I'll respond slower :-)

Best regards, Michael.

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Jordan Wilson <jordan.t.wilson <at> gmx.com>, 65551 <at> debbugs.gnu.org
Subject: Re: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is not
 recognized as an internal or external command...
Date: Mon, 28 Aug 2023 11:01:13 -0700

On 8/28/2023 10:33 AM, Michael Albinus wrote:
> tramp-remote-path is just a template, It is taken the very first time
> you connect to a remote host in order to determine proper PATH
> settings. The result is cached in the connection property "remote-path".

Yeah, I believe this result is where we get the starting value for PATH 
for remote hosts. If we don't already have a cached PATH for the remote 
host in Eshell, we get it by calling '(exec-path)', which I'm guessing 
uses tramp-remote-path (at least indirectly).

> If a user changes PATH for a remote connection in eshell (I don't recall
> how, but I'm sure it is possible in Eshell), you just have to change the
> respective connection property "remote-path" in Tramp.
> See (info "(tramp) Predefined connection information")

Changing the PATH is pretty simple: just run "export PATH=blah" or "set 
PATH blah".

> There is an exception: If a user has the symbol tramp-own-remote-path
> in tramp-remote-path, the cached value is not used for a new process,
> and PATH is recomputed based on tramp-remote-path.

I think we want to handle this case too: for example, I use 
'tramp-own-remote-path' so that I can pick up my remote hosts' PATH 
values, but then I might want to change that value in Eshell later. If 
Eshell let-binds and sets 'tramp-remote-path' when starting the remote 
process, it can override the 'tramp-own-remote-path' setting 
temporarily, which I think is what we want. We'd lose the ability for 
Tramp to recompute the remote PATH on its own, but in the context of 
Eshell I think that should be ok.

> Writing this, it sounds to me too complex. OTOH, no other package has
> tried yet to play with the remote PATH. There are bug reports by users
> who request a simplification (bug#61926, bug#62326). Perhaps it is time
> to redesign the machinery in Tramp.

Yeah, this is pretty tricky code to work with on both sides (both 
Tramp/remote connections and Eshell). One option that might make sense 
is if we could pass the environment vars for the subprocess as a key in 
'make-process', like ':env'. That would let us make sure that the env 
vars are only used exactly where we want them.

For the Eshell side, I think this bug has shown that it's time to review 
how it handles environment variables in general for remote hosts. 
Another interesting bug is how we set PWD and OLDPWD to Tramp filenames 
on remote hosts. When running an external process on that host, we 
should probably use the local file name instead, since non-Emacs 
programs won't understand our remote file syntax.

I'm sure there are other bugs besides that too. Maybe the default 
behavior for env vars is that they should be connection-local (so remote 
hosts don't see your env vars), and then we can opt into passing certain 
special vars (like TERM) to all remote hosts. I'll think about this some 
more and file a bug when I have something more concrete.

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Jordan Wilson <jordan.t.wilson <at> gmx.com>, 65551 <at> debbugs.gnu.org
Subject: Re: bug#65551: 29.1; Eshell on MS-Windows using plink: 'plink' is not
 recognized as an internal or external command...
Date: Thu, 7 Sep 2023 18:18:42 -0700

Version: 29.2

On 8/28/2023 9:53 AM, Jim Porter wrote:
> On 8/28/2023 9:47 AM, Jim Porter wrote:
>> On 8/28/2023 9:29 AM, Jim Porter wrote:
>>> How about something like this? It's a little less invasive (but no 
>>> less of a hack).
>>
>> Oops, something more like this (let-binding 'tramp-remote-path').
> 
> Uh... the third time's the charm I guess? (Sorry for the extra emails.)

Merged this to the Emacs 29 branch as 2af092741e5. Let's keep this open 
to discuss a less-hacky solution for Emacs 30, though.

Previous Next

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