GNU bug report logs -
#29149
Tramp shell uses local shell setting in windows
Previous Next
Reported by: Shuguang Sun <shuguang <at> gmail.com>
Date: Sun, 5 Nov 2017 04:11:01 UTC
Severity: normal
Merged with 29442
Done: Michael Albinus <michael.albinus <at> gmx.de>
Bug is archived. No further changes may be made.
Full log
Message #47 received at 29149 <at> debbugs.gnu.org (full text, mbox):
Shuguang Sun <shuguang <at> gmail.com> writes:
> Hi Michael,
Hi Shuguang,
> Here I focus on the connection from Windows local to linux remote
>
> 1. For the shell command:
> The setting below from 6.5.2 does make the shell command work.
> (connection-local-set-profile-variables
> 'remote-bash
> '((explicit-shell-file-name . "/bin/bash")
> (explicit-bash-args . ("-i"))))
>
> It must specify the explicit-shell-file-name. Otherwise, once the code
> in function shell trying to set explicit-shell-file-name sill has
> bugs:
> 1.1 expand-file-name will add c:/ to the shell-file name because the
> local is windows
> 1.2 the default directory for read-file-name is better to use
> (file-remote-p default-directory) "/" than default-directory
> "/path/path/..."
>
> Otherwise this part of code is not necessary.
>
> 2. 6.5.3 Running ‘shell-command’ on a remote host or other section
> can't solve "start /b" issue. It is introduced by
> dired-do-shell-command (in dired-aux.el). It checks w32-shell for
> local environment and then add "start /b" to the command. However if
> it is in a tramp dir (e.g. linux server), the command with "start /b"
> will be transpose to remote handler. The linux shell can't understand
> it.
Next days, I will hijack a Windows machine, and try to reproduce the
problem, and check your proposed patch.
> If Windows to Windows connection will not meet this issue.
???
In this case, Tramp is not involved.
Best regards, Michael.
This bug report was last modified 7 years and 175 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.