Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: detect login shell over tramp #567

Closed
realcomplex opened this issue Jan 6, 2022 · 5 comments · Fixed by #652
Closed

Feature request: detect login shell over tramp #567

realcomplex opened this issue Jan 6, 2022 · 5 comments · Fixed by #652

Comments

@realcomplex
Copy link

Hi! Thanks for a great package; I'm using vterm a lot.

After a little bit of setup I also got vterm to mostly play nice with tramp, and now I can:

  1. Use tramp to navigate to some remote server over ssh.
  2. Open a vterm which will automatically open a shell on that server.

This is great, but there is one detail which is a little annoying for me: all tramp connections using the same method will result in the same shell being opened. This is configured with the vterm-tramp-shells variable; if it for example contains the entry ("ssh" "/usr/bin/zsh"), then vterm will open a zsh shell on every server I connect to over ssh.

The problem of course is that I don't use the same shell on every computer I ssh to. Sometimes it's zsh, sometimes it's bash and sometimes something else. The most defensive option is to use something like "/bin/sh", but that's not very user-friendly. On the other hand, if vterm tries to open a shell which doesn't exist (say, vterm-tramp-shells contains ("ssh" "/usr/bin/zsh") but zsh is not installed on a particular server), then vterm fails silently and doesn't open a terminal. The same happens when vterm-tramp-shells doesn't contain an entry for the current connection method and the default vterm shell doesn't exist on the remote.

I think it would be great if:

  • the default login shell (i.e. the one specified in /etc/passwd) was opened automatically, or
  • we could configure a list of shells, and vterm tries to open each one in turn. (For me, the list would look something like ("/usr/bin/zsh" "/usr/bin/bash" "/bin/sh").)

I can see that this would need a change to the vterm--get-shell function. I'm not proficient enough with tramp to implement the first option, but I could give the second option a try and submit a draft PR if you want. Of course, there are probably other solutions too.

@Silex
Copy link

Silex commented Feb 10, 2022

@realcomplex can you share what config you did to make it work smoothly with TRAMP?

Out of the box "it works" but things like up arrow doens't repeat history but sends ^[[A

@jvillasante
Copy link

Is this in the works?
Is there a workaround?

@aagon
Copy link

aagon commented Jul 25, 2022

@realcomplex

After a little bit of setup I also got vterm to mostly play nice with tramp, and now I can:

  1. Use tramp to navigate to some remote server over ssh.
  2. Open a vterm which will automatically open a shell on that server.

How did you do that ? Would you mind sharing what you did ?

Thanks in advance !

@qhga
Copy link

qhga commented Sep 29, 2022

@realcomplex

After a little bit of setup I also got vterm to mostly play nice with tramp, and now I can:

  1. Use tramp to navigate to some remote server over ssh.
  2. Open a vterm which will automatically open a shell on that server.

How did you do that ? Would you mind sharing what you did ?

Thanks in advance !

For anyone interested in a solution.

If one calls M-x vterm while inside a tramp buffer and the vterm-tramp-shells variable is not correctly populated vterm just "flashes" (opens/closes really fast) and nothing seems to happen. In reality the vterm instance cannot find a login-shell and exits immediately.

;; Otherwise vterm instantly exits
(add-to-list 'vterm-tramp-shells '("ssh" "/bin/bash"))
(add-to-list 'vterm-tramp-shells '("sudo" "/bin/bash"))

@aport
Copy link

aport commented Feb 16, 2023

With this change, vterm over tramp (ssh) only executes /bin/sh. Is that expected? On the remote systems $SHELL is /bin/bash or /bin/zsh depending on the system.

This works well for me on either system:

(with-output-to-string (shell-command "echo -n $SHELL" standard-output))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants