`gix-command` was already using the `command_name` operand to set `$0`
inside `-c` invocations, but the value passed was a fixed literal: `--`
historically (since GitoxideLabs#496) and most recently `"sh"`. Both have the same
shortcoming: they decouple the value the shell uses to identify itself
in diagnostic messages from the shell that is actually running.

The fixed literal `"sh"` improves over `"--"` only when the shell really
is `sh`. When a caller selects a different shell via
`Prepare::with_shell_program(...)`, the shell will still announce itself
as `sh` in any error output. For example, with bash configured and an
invalid command, errors would read `sh: line 1: ...` even though bash
is what produced them.

Derive the value from the shell program itself instead, using the
basename of the path that is passed to `Command::new` for the shell.
Concretely:

  - With the default shell on Unix (`/bin/sh`), `$0` is `sh`. Same as
    before in practice, but no longer hardcoded.
  - With the default shell on Windows (`sh.exe` from Git for Windows),
    `$0` is `sh.exe`, matching what's actually being launched rather
    than a literal that drops the `.exe`.
  - With a customized `shell_program`, `$0` reflects the chosen shell
    (e.g. `bash`, `zsh`), so its diagnostics correctly identify it.

The basename avoids the MSYS2 path-translation surprise that the full
shell path can trigger on Windows, where Cygwin/MSYS2 programs rewrite
absolute Windows paths handed to them via `lpCommandLine`. Filenames
without path separators do not trigger that rewrite.

The construction-test assertions in `gix-command/tests/command.rs` and
`gix-credentials/tests/program/from_custom_definition.rs` are updated
to derive the expected `command_name` slot from the same source (a new
`SH_BASENAME` `LazyLock` alongside `SH`), so the assertions remain
correct on Windows where the basename is `sh.exe` rather than `sh`. The
one test that configures a custom shell
(`single_and_multiple_arguments_as_part_of_command_with_given_shell`)
now expects the basename of its `/somepath/to/bash` argument, i.e.
`bash`, which is what the corrected code will produce there. The
previously-added `spawn::with_shell::dollar_zero_*` tests, which spawn
the shell and read `$0` directly, now pass under this implementation.

Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>

`gix-command` already used the `command_name` operand to set `$0` inside
`-c` invocations, but the value passed was a fixed literal: `--`
historically (since GitoxideLabs#496) and most recently `"sh"`. Both have the same
shortcoming: they decouple the value the shell uses to identify itself
in diagnostic messages from the shell that is actually running.

The fixed literal `"sh"` improves over `"--"` only when the shell really
is `sh`. When a caller selects a different shell via
`Prepare::with_shell_program(...)`, the shell will still announce itself
as `sh` in any error output. For example, with bash configured and an
invalid command, errors would read `sh: line 1: ...` even though bash
is what produced them.

Derive the value from the shell program itself, using the basename of
the path that is passed to `Command::new` for the shell. Concretely:

  - With the default shell on Unix (`/bin/sh`), `$0` is `sh`. Same as
    before in practice, but no longer hardcoded.
  - With the default shell on Windows (`sh.exe` from Git for Windows),
    `$0` is `sh.exe`, matching what's actually being launched rather
    than a literal that drops the `.exe`.
  - With a customized `shell_program`, `$0` reflects the chosen shell
    (e.g. `bash`, `zsh`), so its diagnostics correctly identify it.

The basename avoids the MSYS2 path-translation surprise that the full
shell path can trigger on Windows, where Cygwin/MSYS2 programs rewrite
absolute Windows paths handed to them via `lpCommandLine`. Filenames
without path separators do not trigger that rewrite.

The tests added in the preceding commit now pass under this
implementation, including the construction-test assertions whose
`SH_BASENAME`-derived expected value matches `sh.exe` on Windows and
the bash-specific assertion whose expected value is `"bash"`.

Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>

`gix-command` already used the `command_name` operand to set `$0` inside
`-c` invocations, but the value passed was a fixed literal: `--`
historically (since GitoxideLabs#496) and most recently `"sh"`. Both have the same
shortcoming: they decouple the value the shell uses to identify itself
in diagnostic messages from the shell that is actually running.

The fixed literal `"sh"` improves over `"--"` only when the shell really
is `sh`. When a caller selects a different shell via
`Prepare::with_shell_program(...)`, the shell will still announce itself
as `sh` in any error output. For example, with bash configured and an
invalid command, errors would read `sh: line 1: ...` even though bash
is what produced them.

Derive the value from the shell program itself, using the basename of
the path that is passed to `Command::new` for the shell. Concretely:

  - With the default shell on Unix (`/bin/sh`), `$0` is `sh`. Same as
    before in practice, but no longer hardcoded.
  - With the default shell on Windows (`sh.exe` from Git for Windows),
    `$0` is `sh.exe`, matching what's actually being launched rather
    than a literal that drops the `.exe`.
  - With a customized `shell_program`, `$0` reflects the chosen shell
    (e.g. `bash`, `zsh`), so its diagnostics correctly identify it.

The basename avoids the MSYS2 path-translation surprise that the full
shell path can trigger on Windows, where Cygwin/MSYS2 programs rewrite
absolute Windows paths handed to them via `lpCommandLine`. Filenames
without path separators do not trigger that rewrite.

The tests added in the preceding commit now pass under this
implementation, including the construction-test assertions whose
`SH_BASENAME`-derived expected value matches `sh.exe` on Windows and
the bash-specific assertion whose expected value is `"bash"`.

Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>