8

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?

Joseph Garvin
  • 2,061
  • 8
  • 21

2 Answers2

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.

Emacs User
  • 5,553
  • 18
  • 48
  • 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
  • I use a custom compiled version based on GNU Emacs 25.1.50.2 (x86_64-apple-darwin15.2.0, NS appkit-1404.34 Version 10.11.2 (Build 15C50)). I tested connecting to a remote host that is a linux VM. – Emacs User Jan 27 '16 at 15:55
0

Try circumventing this problem by using Eat's eat-eshell-mode, which gives your Eshell buffer full terminal emulator capabilities: then you can clear the visual command list, so that top - both locally and over TRAMP - runs in Eshell itself, which I suspect would take better advantage of Eshell's normal TRAMP integration than the separate visual command buffers do.

I haven't personally tested this yet, but this is what I'll be reaching for as soon as I run into the same issue.

mtraceur
  • 184
  • 1
  • 10