Esegui l'applicazione in cwd sull'host remoto da eshell

Uso spesso Eshell per connettermi a sistemi remoti. Su quei sistemi remoti a volte voglio eseguire script nella directory di lavoro corrente. In un terminale normale scrivo questo:

./my-script.sh

Sfortunatamente, all'interno di Eshell questo non funzionerà:

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

Funziona solo se fornisco il percorso TRAMP completo allo script:

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

C'è un modo per convincere Eshell ad espandersi .automaticamente in modo tale che la semplice invocazione funzioni?

Come soluzione alternativa, attualmente utilizzo una funzione associata a C-c .quella che inserisce il percorso completo corrente sulla riga di comando. Preferirei di gran lunga .comportarmi come previsto.

Sembra un bug eshell, dovresti segnalarlo.

Penso che tu possa aggiustarlo

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

In conclusione, il problema è che il vagabondo finisce per costruire una riga di comando remota del modulo (sto rimuovendo un po 'di escape per renderlo più chiaro):

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

Ecco perché finisci con quel messaggio "misterioso" su env

Ciò che deve invece generare (ed è quello che si ottiene dal comando sopra) è qualcosa di simile

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

Credo che il bug sia sul lato eshell, dato che il vagabondo non ha modo di sapere che "/ ssh: remote1: ..." non è un comando remoto valido (anche se se lo fosse, probabilmente avremmo molto di più problemi con il vagabondo multi-hop ... ma comunque). Ed eshell fa davvero la cosa sana quando il comando è esplicitamente un percorso vagabondo.