Uruchom aplikację w cwd na zdalnym hoście z poziomu eshell

Często używam Eshell do łączenia się ze zdalnymi systemami. Na tych zdalnych systemach czasami chcę uruchamiać skrypty w bieżącym katalogu roboczym. W zwykłym terminalu wpisałbym to:

./my-script.sh

Niestety wewnątrz Eshella to nie zadziała:

~ $ 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 $ 

Działa to tylko wtedy, gdy podam pełną ścieżkę TRAMP do skryptu:

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

Czy istnieje sposób przekonania Eshell do .automatycznego rozszerzenia, tak aby działało prostsze wywołanie?

Jako obejście używam obecnie funkcji powiązanej z C-c .tą, która wstawia bieżącą pełną ścieżkę do wiersza poleceń. Wolałbym .zachowywać się zgodnie z oczekiwaniami.

To wygląda na błąd eshell, powinieneś to zgłosić.

Myślę, że możesz to naprawić

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

Podsumowując, problem polega na tym, że tramp konstruuje zdalną linię poleceń formularza (usuwam niektóre znaki ucieczki, aby było jaśniej):

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

Dlatego właśnie kończy się ta „tajemnicza” wiadomość env

Zamiast tego musi wygenerować (i właśnie to osiągnięto dzięki powyższemu poleceniu)

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

Sądzę jednak, że błąd występuje po stronie skorupy, ponieważ tramp nie ma sposobu, aby wiedzieć, że „/ ssh: remote1: ...” nie jest prawidłową komendą zdalną (chociaż gdyby tak było, prawdopodobnie mielibyśmy znacznie więcej problemy z trampem multi-hop ... ale i tak). I eshell rzeczywiście robi rozsądną rzecz, gdy polecenie jest wyraźnie ścieżką włóczęgi.