Execute o aplicativo no cwd no host remoto a partir do eshell

Costumo usar o Eshell para conectar-me a sistemas remotos. Nesses sistemas remotos, às vezes, quero executar scripts no diretório de trabalho atual. Em um terminal regular, eu digitaria o seguinte:

./my-script.sh

Infelizmente, dentro do Eshell isso não funcionará:

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

Funciona apenas se eu fornecer o caminho completo do TRAMP para o script:

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

Existe uma maneira de convencer Eshell a expandir .automaticamente, de modo que a chamada mais simples funcione?

Como solução alternativa, atualmente uso uma função vinculada a C-c .que insere o caminho completo atual na linha de comando. Eu preferiria ter .apenas me comportado como esperado.

Parece um bug eshell, você deve denunciá-lo.

Eu acho que você pode consertar isso

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

Resumindo, o problema é que o vagabundo acaba construindo uma linha de comando remota do formulário (estou removendo alguns escapes para torná-lo mais claro):

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

É por isso que você acaba com essa mensagem "misteriosa" sobre env

Em vez disso, o que ele precisa gerar (e é isso que é obtido pelo comando acima) é algo como

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

Eu acredito que o bug está do lado do eshell, já que o vagabundo não tem como saber que "/ ssh: remote1: ..." não é um comando remoto válido (embora, se fosse, provavelmente teríamos muito mais problemas com o vagabundo multi-hop ... mas de qualquer maneira). E eshell realmente faz a coisa certa quando o comando é explicitamente um caminho lento.