https://bugs.kde.org/show_bug.cgi?id=490432
Bug ID: 490432
Summary: ~/.config/plasma-workspace/env startup scripts cannot
set a variable as empty
Classification: Plasma
Product: plasmashell
Version: 6.0.5
Platform: NixOS
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Startup process
Assignee: plasma-b...@kde.org
Reporter: hexclo...@outlook.com
CC: k...@davidedmundson.co.uk
Target Milestone: 1.0
SUMMARY
Plasma workspace allows the user to set environment variables in .sh files
located in ~/.config/plasma-workspace/env. However, if one sets a variable to
the empty string, it does not get exported into the plasma process.
STEPS TO REPRODUCE
Put these into ~/.config/plasma-workspace/env/foo.sh and give it +x permission:
```bash
export SHOULD_BE_ONE=1
export SHOULD_BE_NONE=
```
Then boot KDE.
OBSERVED RESULT
SHOULD_BE_ONE is 1 but SHOULD_BE_NONE is unset.
EXPECTED RESULT
SHOULD_BE_NONE should be set to the empty string (should appear in the output
of `env`).
SOFTWARE/OS VERSIONS
Operating System: NixOS 24.05
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.2
Graphics Platform: Wayland
ADDITIONAL INFORMATION
To fix the problem, arguably we should fix this function in `startplasma.cpp`:
```cpp
void setEnvironmentVariable(const char *name, QByteArrayView value)
{
if (qgetenv(name) != value) {
qputenv(name, value);
}
}
```
`qgetenv` is documented to return the an empty byte array if the variable is
unset, so `gputenv` is not called.
This behavior is not always problematic, but consider the following situation.
Suppose some env var `X` is set in the DBus environment already, but the user
would like to use the value they specified. `startplasma-wayland.cpp` does
three things in order:
1. Source `env/*.sh` and import the env vars by calling
`runEnvironmentScripts()`
2. Sync environment to DBus by calling `syncDBusEnvironment()`
3. Import systemd env vars by calling `importSystemdEnvrionment()`
If in the .sh file `X` is set, it should be imported into the plasma process in
step 1, then exported to DBus in step 2, so step 3 just re-import that exported
value, which is set by the user. However, if the user sets `X` to be empty in
the script, then it won't get pass step 1, so the value from systemd will be
used after step 3.
--
You are receiving this mail because:
You are watching all bug changes.
