bug#31704: 26.1; tramp-remote-path/shell: broken executable completion

bug#31704: 26.1; tramp-remote-path/shell: broken executable completion

[xristos]

The issue lies in shell--command-completion-data which is called
by shell-command-completion, it only checks directories in
exec-path (local) rather than tramp-remote-path. This bug also
leaks the local exec-path to the remote server.

To reproduce:

emacs -Q

Evaluate:
(require 'tramp)

;; For debugging
(setq tramp-persistency-file-name nil
      tramp-verbose 10)

(add-to-list 'tramp-remote-path 'tramp-own-remote-path)

;; Assuming an account 'chris' exists at server 'remote',
;; to see the issue clearly make sure that there exists
;; a directory in the remote server PATH (e.g. ~/bin/)
;; but NOT in exec-path.

(let ((default-directory "/ssh:chris@remote:"))
  (shell "*remote*"))

;; Assuming executable 'testbin' exists in remote server ~/bin/
;; and not inside any directory in exec-path:

remote$ testb<TAB> ;; No completion

M-:
(add-to-list 'exec-path "~/bin/")

remote$ testb<TAB> ;; Completes fine

If one checks the tramp debug buffer, one will see tramp
checking (and leaking information to the remote server)
all the directories that exist in the local exec-path.

bug#31704: 26.1; tramp-remote-path/shell: broken executable completion

[Michael Albinus]

xristos <xristos@sdf.org> writes:

Hi,

> The issue lies in shell--command-completion-data which is called
> by shell-command-completion, it only checks directories in
> exec-path (local) rather than tramp-remote-path. This bug also
> leaks the local exec-path to the remote server.

I have been bitten several times over the last years by this
problem. Not enough energy to track it down.

I will take your bug report as motivation to give it a try for
fixing. Likely not Just Now, but next time, somehow. I fear, there's no
simple solution.

Best regards, Michael.

bug#31704: 26.1; tramp-remote-path/shell: broken executable completion

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

Hi,

>> The issue lies in shell--command-completion-data which is called
>> by shell-command-completion, it only checks directories in
>> exec-path (local) rather than tramp-remote-path. This bug also
>> leaks the local exec-path to the remote server.
>
> I have been bitten several times over the last years by this
> problem. Not enough energy to track it down.
>
> I will take your bug report as motivation to give it a try for
> fixing. Likely not Just Now, but next time, somehow. I fear, there's no
> simple solution.

Finally, I've implemented this. If you have a chance to build Emacs from
the git repository, you could try it.

Best regards, Michael.

bug#31704: fixed commit not handle eshell-path-env properly in Windows platform

[fangtao0901]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]


Hi, Michael  I'm using git master branch daily build emacs on Windows platform, after this commit to fix bug#31704, running commands directly in eshell always gives output "command not found".  The cause of this is in lisp/net/tramp.el, function tramp-eshell-directory-change modify eshell-path-env not properly:  (mapconcat 'identity (butlast (tramp-compat-exec-path)) ":")  I think variable path-separator should be used instead of ":"
Best regards,

[-- Attachment #2: Type: text/html, Size: 687 bytes --]

bug#31704: fixed commit not handle eshell-path-env properly in Windows platform

[Michael Albinus]

fangtao0901 <fangtao0901@gmail.com> writes:

> Hi, Michael

Hi,

>   I'm using git master branch daily build emacs on Windows platform,
> after this commit to fix bug#31704, running commands directly in
> eshell always gives output "command not found".
>   The cause of this is in lisp/net/tramp.el, function
> tramp-eshell-directory-change modify eshell-path-env not properly:
>   (mapconcat 'identity (butlast (tramp-compat-exec-path)) ":")
>   I think variable path-separator should be used instead of ":"

I confirm the problem. However, your proposal doesn't fix it for me.

Are you sure this is a new problem? I've tried Emacs 26.1 on MS Windows,
and I get a similar error.

> Best regards,

Best regards, Michael.

bug#31704: fixed commit not handle eshell-path-env properly in Windows platform

[Tao Fang]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

Hi, Michael >   Are you sure this is a new problem? Yes, previous code snippet using (getenv "PATH") when tramp not involved which is right result, I've tested this by revert this commit. >   I've tried Emacs 26.1 on MS Windows, and I get a similar error. Have you added related path to PATH environment variable, e.g. d:\emacs-26.1-x86_64\bin ? I've download Emacs 26.1 from http://ftp.gnu.org/gnu/emacs/windows/emacs-26/emacs-26.1-x86_64.zip and it shows fine. Best regards,

[-- Attachment #2: Type: text/html, Size: 938 bytes --]

bug#31704: fixed commit not handle eshell-path-env properly in Windows platform

[Michael Albinus]

Tao Fang <fangtao0901@gmail.com> writes:

> Hi, Michael

Hi,

>> I've tried Emacs 26.1 on MS Windows, and I get a similar error. 
> Have you added related path to PATH environment variable, e.g.
> d:\emacs-26.1-x86_64\bin ? I've download Emacs 26.1 from
> http://ftp.gnu.org/gnu/emacs/windows/emacs-26/emacs-26.1-x86_64.zip
> and it shows fine.

I've committed a patch to the master branch to fix this problem for MS
Windows. I've fixed also a second problem, where Emacs has prefixed
remote file names with the MS Windows volume letter.

Could you pls check?

> Best regards, 

Best regards, Michael.

bug#31704: fixed commit not handle eshell-path-env properly in Windows platform

[Tao Fang]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

Hi, Michael  I can confirm this bug was fixed in your commit and second problem fixed either, thanks! Best regards, On 09/06/2018 18:21, Michael Albinus wrote: Tao Fang <fangtao0901@gmail.com> writes: > Hi, Michael Hi, >> I've tried Emacs 26.1 on MS Windows, and I get a similar error. > Have you added related path to PATH environment variable, e.g. > d:\emacs-26.1-x86_64\bin ? I've download Emacs 26.1 from > http://ftp.gnu.org/gnu/emacs/windows/emacs-26/emacs-26.1-x86_64.zip > and it shows fine. I've committed a patch to the master branch to fix this problem for MS Windows. I've fixed also a second problem, where Emacs has prefixed remote file names with the MS Windows volume letter. Could you pls check? > Best regards, Best regards, Michael.

[-- Attachment #2: Type: text/html, Size: 1846 bytes --]

bug#31704: fixed commit not handle eshell-path-env properly in Windows platform

[Michael Albinus]

Version: 27.1

Tao Fang <fangtao0901@gmail.com> writes:

> Hi, Michael

Hi,

>  I can confirm this bug was fixed in your commit and second problem
> fixed either, thanks!

Thanks for your confirmation, I'm closing the bug.

> Best regards,

Best regards, Michael.