6

I know that I can add commands to eshell-visual-commands to for example make it so when I run "top" it runs in a temporary ansi-term buffer instead of the eshell buffer, so that programs that rely on complex terminal stuff work seamlessly with eshell.

But I'd like them to work when using eshell's tramp integration too. So I can cd to another machine with:

cd /ssh:myuser@myhost:/

Which then takes me to that machine, ls shows the right files, and everything working nice as long as I don't use a visual command. But as soon as I try to run top there I get a term buffer that's empty except for this output:

..: 1: exec: /ssh:myuser@myhost:/usr/bin/top: not found

I have verified /usr/bin/top exists on the machine, and that this happens even when using emacs -Q so I think the issue is just that eshell-visual-commands assumes that whatever it gets back from running "which top" is what it should run in a term buffer, not understanding that that term buffer first needs to be ssh'd into the other machine. Has anybody else tackled making this work?

1

One workaround I've been using is to trigger a local shell on the remote host for visual commands:

cd /ssh:myuser@myhost:/
*ssh localhost "top"

The * ensures eshell does not use any built-in commands when available. Of course ssh-agent running on the remote host will help with pwd-less interactions.

  • When I try this locally, I just get an error about TERM not being set. if I manually add ssh to my list of visual commands, then I get the same error just in a term buffer. do you have some emacs lisp magic to go along with this? – Joseph Garvin Jan 25 '16 at 18:36
  • My term=dumb, which is what you want as any other will interfere with the visual commands. Same with elisp magic, you don't want any elisp in the way. See if term is being changed on the remote or force the setting through ssh config. – Emacs User Jan 26 '16 at 11:16
  • I discovered passing the "-t" flag to ssh will get rid of the error, and then I get a different problem, which is an emacs lisp backtrace complaining that /usr/bin/ssh failed, even though my test program top is running and displaying fine. – Joseph Garvin Jan 26 '16 at 23:01
  • interesting, I only get that error if I use *ssh instead of just ssh – Joseph Garvin Jan 26 '16 at 23:06
  • For my last couple comments I was testing either using ssh to localhost on my own box, or using ssh to remotehost still from a local folder. When I change directory to the other host first like you described, I get the same error I originally did in my post, even with the leading *. what emacs version are you on? OS? – Joseph Garvin Jan 27 '16 at 15:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.