Run application in cwd on remote host from within eshell

Question

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:

./my-script.sh

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.

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.