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
One of the `justfile` recipes ran `just --fmt --unstable`, and did
so as such. The problem with this is that the `just` executable in
the outer `just` call is not guaranteed to be the same `just` that
the inner call in the recipe finds. For example:
- In general, a user might use a `just` that is not in `$PATH` even
when another `just` is in `$PATH`. This would happen when testing
changes to `just`, and potentially in other use cases.
- The "inner" `just` is looked up by a POSIX-compatible shell that,
on Windows, may have a changed environment. For example, the
`sh.exe` shim provided by Git for Windows modifies environment
variables including placing some directories in the front of
`$PATH`. (See discussion in GitoxideLabs#1864 for details.)
Thus `just` provides a built-in function `just_executable()` that
can be used, and which we already use in the default recipe.
This uses that function instead. However, it is not as simple as
`{{ just_executable() }} --fmt --unstable`, because the path may
require quoting to be run in a shell.
In practice, it almost always needs to be quoted on Windows, where
otherwise a `\` is being given to the shell (which the shell is
required to interpret as a quoting character; this is distinct from
a scenario where a path might be passed as an argument to a shell,
in which case strange things may or may not occur). It might rarely
need to be quoted on other systems too, it it has spaces or other
even weirder contents.
So this uses `{{ quote(just_executable()) }}`. It does so through
the `j` variable that has already been assigned that value.
0 commit comments