Fix SSH remotes running Nushell

[notpeter]

• Closes: Remote Development - Cannot connect if default shell on remote machine is Nushell #21005

Nushell does not support uname -sm
So invoke sh -c "uname -sm" instead which will also work under nushell.
See nushell/nushell#12570 for the choice quote: "being posix/bash compliant is a non-goal"

Release Notes:

• Fixed ssh remotes running Nushell

[zed-industries-bot]

	Messages
📖	This PR includes links to the following GitHub Issues: #21005, #nushell/nushell#12570 If this PR aims to close an issue, please include a Closes #ISSUE line at the top of the PR body.

Generated by 🚫 dangerJS against 68f0cf0

[jaredramirez]

Hey, thanks for looking into this! I may be missing something, but the following does not work for me in nushell:

$ uname -s -m
Error: nu::parser::unknown_flag

  × The `uname` command doesn't have flag `-s`.
   ╭─[entry #103:1:8]
 1 │ uname -s -m
   ·        ┬
   ·        ╰── unknown flag
   ╰────
  help: Available flags: --help(-h). Use `--help` for more information.

[jaredramirez]

Related Nushell issue here: nushell/nushell#12570

A non-exhaustive list of workarounds:

Run uname in sh

A simple option would be to run the command sh -c 'uname -sm' instead, which would work no matter what shell is default on the remote machine. But this assumes that sh is available on the path, which is likely to be true, but maybe not guaranteed?

Try nushell-specific command on error

Another possible workaround is if we can detect if we're in Nushell, we could run a nushell-specific command to get the relevent data from uname.

For example, if we can assume that an error here:

self.socket.run_command("uname", &["-sm"]).await?;

indicates that we're in Nushell, then we could ignore the error and instead run the nushell-equivalent command:

$"((uname).kernel-name) ((uname).machine)"

Which prints Linux x86_64, just like uname -sm.

There could be a better way to detect the shell beyond assuming an error on that line means we're in nushell

[notpeter]

Thanks @jaredramirez. I obviously was mistaken, but I could've sworn I had gotten uname -s -m worked in nushell.

I hadn't merged this because I hadn't figured how to test it. Forcing this code path in dev likely requires some scaffolding (normally ssh remoting in dev cross-compiles zed-remote-server on your local machine instead of downloading a specific release).

@ConradIrwin Do you know if there an easy way to get zed to use a specific release binary for the remote in dev?

[ConradIrwin]

@notpeter you "just" need to put the one you want as an executable called ~/.zed_server/zed-remote-server-dev-build.

We changed the default, so cargo run ssh://dev/path just fails if this does not exists. If you export ZED_BUILD_REMOTE_SERVER=1 it'll build a new one and upload it over the top.

[notpeter]

@ConradIrwin that's super helpful and I'll add it to the docs.

I tested this with nu and bash on my remote so I think this will work:
run_command("sh", &["-c", "uname -sm"])

Thanks