bug#29149: Tramp shell uses local shell setting in windows

[Shuguang Sun]

On Thu, Jan 25, 2018 at 8:30 PM, Michael Albinus <michael.albinus@gmx.de> wrote:

Shuguang Sun <shuguang@gmail.com> writes:

> Thanks Micahel,

Hi Shuguang,

> Now it works!

Thanks for testing. So I mark this bug as closed.

>     > 1.2 the default directory for read-file-name is better to use
>     > (file-remote-p default-directory) "/" than default-directory
>     > "/path/path/..."
>
>     I don't see why. Could you pls explain?
>
> If we well set the shell via connection-local-set-profile-variables
> which measn there is explicit-shell-file-name, it will not prompt the
> directory.
>
> For example as in the manual:
>   (connection-local-set-profile-variables
>    'remote-bash
>    '((explicit-shell-file-name . "/bin/bash")
>      (explicit-bash-args . ("-i"))
>      ))

Hmm. I still don't understand why you want to change
default-directory. Or do you want to say it doesn't matter, when
explicit-shell-file-name is set?

From the logic, when explicit-shell-file-name is set, the read-file-name will not be triggered. So it doesn't matter.

And even in case there is no explicit-shell-file-name set,
read-file-name shall work as expected with the existing default-directory.

If there is no explicit-shell-file-name set when local windows and remote nix-llike, the read-file-name will

1. put the shell-file-name "c:/..../cmdproxy.exe" after the default directory in the minibuffer prompt. User has to delete those things. 

2. Usually the shell file is more close to root "/" than the the default directory (which is the HOME or even deeper). User has to delete characters to the root and then find the shell file.

 User experience may need improvement.

Best regards, Michael.