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.
    – rekado
    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/…
    – rekado
    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, privacy policy and cookie policy

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