Re: Strange prompt in tramp remote shell

[Michael Albinus]

"Christian Millour (AB TELA)" <address@hidden> writes:

> That might be wasteful though, as I guess that you need separate
> ssh/plink sessions for shell and transfers, whereas with a tramp shell
> the session is shared ?

There is a separate session to the remote host, when `process-file' is
called. And this is the case indeed, as it is called from inside `shell'.

> Old habits die hard and it would be nice (for me at least) if it were
> possible to get the tramp remote shell *before* opening any remote
> file. Because this is the way I naturally operate : remote log in, do
> shell stuff, maybe navigate to the directory I want, and maybe C-x C-f
> a file there. With tramp I need to open a file even if all I need is
> the remote login. This means I generally open the remote home dir in
> dired, and end up not using it. Oh well. I can live with this :-)

It is sufficient to have `default-directory' pointing to the remote
host. Try this command:

--8<---------------cut here---------------start------------->8---
(defun my-remote-shell (buffer dir)
  (interactive
   (list
    (read-buffer "Shell buffer: "
                 (generate-new-buffer-name "*shell*"))
    (expand-file-name
     (read-file-name
      "Default directory: " default-directory default-directory
      t nil 'file-directory-p))))
  (let ((default-directory dir))
    (shell buffer)))
--8<---------------cut here---------------end--------------->8---

When asked for the directory, type something like "/plink:remotehost:"

An alternative would be to use "M-x eshell". You can run it for a local
directory, and then you could cd to the remote host (in Tramp syntax),
for example

~ $ cd /sudo::
/sudo:address@hidden:/root $

>> That looks like a reasonable handling of the problem. The variable
>> $INSIDE_EMACS is set exactly for the purpose to give the user a chance
>> to react on Tramp specifics. And you do.
>>
>> If you do not object, I will add your recipe to Tramp's FAQ.
>>
> Please feel free to do so, but note that if you access various boxen
> with different shells the (setenv "ESHELL" ...) is unwieldy.

Yes, we need a recipe to set environment variables dedicated for a given
remote host. It is a major disadvantage that environment variables
cannot be set host specific. On my todo list for a long time, but I have
no clue yet what to do.

> Thanks again, and best regards,
>
>   Christian

Best regards, Michael.