You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This adds regression tests for the values the `$0` command name
special parameter, and the `$@` positional parameters special
parameter, when `gix-command` runs a shell script file whose path
is specified as the value of a `Prepare` instance's `command`
field:
- `"$0"` expands to that path.
- `"$@"` expands to the arguments passed to the script.
- Neither contain any interpreter name, added quotes, placeholders.
That holds whether the script is run directly, as would typically
be the case, as well as when it is run indirectly through an
intermediate shell instance, regardless of how that is done. The
latter, while presumably uncommon, must also not affect what `"$0"`
and `"$@"` expand to in the script.
These regression tests already pass on Unix-like systems. If they
don't pass on Windows, then it *may* be that these new tests should
be adjusted, rather than the code under test. But it is important
that the behavior of the code under test still confirms to the
above description, modulo path style transformations.
In particular, even on Windows, even if a shell is invoked
differently, `$0` should expand to a path to the script, and *not*
to the interpreter or anything else.
But the path might potentially be altered, such as by changing `\`
to `/`, otherwise normalizing or even canonicalizing it differently,
and maybe even turning into a Cygwin/MSYS/MSYS2-style path. If
necessary, the `$0` assertions on Windows could be weakened to
assert, when it is parsed as a path, that the last path component
is the script filename.
Even more than to check that we already have reasonable `$0`
behavior even on Windows, the motivation for these tests relates to
a forthcoming change to an altogether *different* case of using a
shell: when a command like `sh -c` is used. There, the command name
argument that follows `-c` is currently `--`, which is misleading
because it does not relate to the usual meanings of `--`, and which
is not very informative (when `$0` is expanded for error or warning
messages). As discussed in #1840, this shall be changed, probably
to give the shell name.
These regression tests for behavior that must *not* be affected by
that forthcoming change serve three purposes related to it:
- Clearly express to human readers that `$0` inside a script file
expands to a path to the file that was used to run the script,
regardless of how that file is being run: directly (relying on
its shebang), by being passed explicitly to an interpreter, or by
appearing as the operand to `-c`. The latter case must *still*
behave this way under the forthcoming change, because that change
will affect what `$0` appearing directly in the operand of `-c`
expands to, *not* what it expands to in a subprocess created by
`sh -c` that opens a separate script file containing occurrences
of `$0` that the shell expands.
In particular, these tests can be compared to fortcoming tests
covering the case that *will* be changed.
- Check that this requirement is not broken under the forthcoming
change.
- Check that this requirement is not broken under later changs
that are not currently anticipated.
0 commit comments