UnsetEnvironment= was applied to the environment block before the
command line was expanded. Since the expansion looks the variables up
in that same block, any variable listed in UnsetEnvironment= was
already gone when $VAR in ExecStart= and friends was expanded, and a
whole-word $VAR reference was dropped from the command line.
Let the expansion see the full environment block, and apply the
unsetting only to the environment block passed to the executed
process. This way UnsetEnvironment= can hide variables from the
executed process without breaking command lines that reference them.
Extend the exec-unsetenvironment test accordingly: the whole-word
$VAR6 argument must be expanded into a positional parameter for the
shell, while ${VAR6-X} must evaluate to X in the executed process.
Also document in both the UnsetEnvironment= description and the
"Environment Variables in Spawned Processes" section that the
unsetting happens after command line variable expansion.
Fixes: #43343
If sh is not bash, some builtin command behave slightly differently.
E.g. if sh is provided by busybox, its builtin test command does not check if
the path is a mount point or not, and 'test -w' only checks the access mode of
the inode. So, even if a readonly filesystem is mounted on a directory,
the test command may succeed.
To avoid such confusion, let's unconditionally use bash.
We want to retain *some* of the full paths in order to test more code paths.
But the default should be to use the command name only. This makes the tests
less visually cluttered.
Those are all consumed by our parser, so they all support comments.
I was considering whether they should have a license header at all,
but in the end I decided to add it because those files are often created
by copying parts of real unit files. And if the real ones have a license,
then those might as well. It's easier to add it than to make an exception.
tunaichao
Yu Watanabe
Zbigniew Jędrzejewski-Szmek