I often use Eshell to connect to remote systems. On those remote systems I sometimes want to run scripts in the current working directory. In a regular terminal I'd type this:


Unfortunately, inside of Eshell this won't work:

~ $ cd /remote1:~
/ssh:remote1:/home/rekado $ ./my-script.sh 
env: /ssh:remote1:/home/rekado/my-script.sh: No such file or directory
/ssh:remote1:/home/rekado $ 

It only works if I provide the complete TRAMP path to the script:

/ssh:remote1:/home/rekado $ /ssh:remote1:/home/rekado/my-script.sh 
It works!
/ssh:remote1:/home/rekado $ 

Is there a way to convince Eshell to expand . automatically such that the simpler invocation just works?

As a workaround I currently use a function bound to C-c . that inserts the current full path on the command line. I'd much prefer to have . just behave as expected.

1 Answer 1


That looks like a bug in eshell, you should report it.

I think you can fix it by

(defadvice eshell-gather-process-output (before absolute-cmd (command args) act)
  (setq command (file-truename command)))

Bottom-line, the problem is that tramp ends up constructing a remote command line of the form (I'm removing some escaping to make it clearer):

cd /home/rekado && exec env PS1='/ssh:remote1:/home/rekado $' /ssh:remote1:/home/rekado/my-script.sh

Which is why you end up with that "mysterious" message about env

What it needs to generate instead (and that's what's achieved by the command above) is something like

cd /home/rekado && exec env PS1='/ssh:remote1:/home/rekado $' /home/rekado/my-script.sh

I do believe the bug is on the eshell side though, since tramp has no way of knowing that "/ssh:remote1:..." is not a valid remote command (although if it was, we'd probably have a lot more problems with multi-hop tramp... but anyways). And eshell indeed does the sane thing when the command is explicitly a tramp path.

  • Works smoothly. Thanks for this solution. Oct 13, 2014 at 17:48
  • 1
    It is a bug indeed and has been fixed upstream already.
    – user2005
    Jan 24, 2015 at 9:51
  • @rekado, Which version of emacs is it fixed in? Apr 9, 2015 at 15:11
  • I believe it was fixed with this commit: git.savannah.gnu.org/cgit/emacs.git/commit/…
    – user2005
    Apr 10, 2015 at 3:54
  • I encountered this bug and had to apply the above fix (which corrects the problem --- thank you for that). I am running emacs 24.5.1 installed via homebrew on a mac. The upstream fix does not correct the problem for me.
    – butala
    Nov 5, 2015 at 18:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.