bug#61748: 27.2; Eglot should use shell-file-name when launching the language server for a remote file

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 24 Feb 2023 08:39:45 +0100 (CET)
> From: jeberger@free.fr
> 
> >From https://github.com/joaotavora/eglot/issues/1175
> 
> # Steps to reproduce:
> 
> - On the remote machine:
>     - Install a language server in a non-standard path (e.g. `rust-analyzer`, which installs in a subdirectory under `$HOME` and not `/usr/bin`)
>     - Make sure that the server is in the path for a shell other than `sh` (e.g. set the path in `.zprofile` for `zsh`).
> - On the local machine:
>     - Open a file remotely through TRAMP
>     - Set `shell-file-name` to the shell you're using on the remote (e.g. `(setq shell-file-name "zsh")`)
>     - <key>M-x</key> `eglot`.
> 
> # Expected result:
> 
> Eglot should start
> 
> # Actual result:
> 
> Eglot asks `Enter program to execute (or <host>:<port>):`, then when I type `rust-analyzer` it fails with message `[jsonrpc] Server exited with status 127`. Looking at `eglot-events-buffer`, it is clear that eglot tried to use `sh` to start the server.
> 
> # Partial fix
> 
> The server starts correctly if I change function `eglot--cmd` to use `(or shell-file-name "sh")` instead of plain `"sh"`, e.g.:

I don't think this is the correct fix.  The literal "sh -c" is used in
Eglot only for remote server invocations, and I presume this was done
to avoid the problems with running Eglot on MS-Windows.  Using
shell-file-name is incorrect for this use case because shell-file-name
gives you the name of the _local_ shell.  I think we have better ways
of dealing with this issue' I've CC'ed Michael in the hope that he
will tell how to solve this properly.

Thanks.