Hi Michael,

Thank you for your patient explanition. Now it is very clear to me.

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

> Shuguang Sun <shuguang@gmail.com> writes:
>
> Hi Shuguang,
>
> >     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.exeS" 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.
>
> You get the default in the minibuffer like
> "/plink:remotehost:<default-directory><shell-file-name>". The prompt is
> between <default-directory> and local <shell-file-name>. You do NOT need
> to delete anything from <default-directory>, delete the local
> <shell-file-name> by C-k, which must be done anyway. Then, simply type
> "/path/to/my/shell" (for example, "/bin/bash"). Note the resulting
> double-slash between <default-directory> and what you have typed! This
> works due to the electricity of file name completion in the
> minibuffer. This is roughly the same as typing the shell file name from
> the remote host's root directory.
>
> See also (info "(tramp) File name completion")
>
> Best regards, Michael.
>