| Summary: | After update from plasma5 2.24.4 to 5.27.4, when not using Systemd boot, scripts executed in terminals cannot change directory | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | davejplater@gmail.com <plater> |
| Component: | Startup process | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | kde, nate, vkrevs |
| Priority: | NOR | ||
| Version First Reported In: | 5.27.4 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
davejplater@gmail.com
2023-06-13 15:41:07 UTC
I've updated the title to reflect the true problem that scripts such as:
#! /usr/bin/bash
dirc()
{
pushd ../../
}
dirc
don't work in kde anymore ie. the above script does nothing unless it is prepended with the bash builtin "." which forces the script to execute in the current shell. This wasn't the case in version 5.24.4 but is now the case in 5.27.4
If this behavior has been introduced as a security feature, I would appreciate knowing when and why.
Sorry, I would like to know the commit's hash. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! It appears that this bug appeared after plasma 5.26. See also: https://bugzilla.suse.com/show_bug.cgi?id=1213156 https://bugs.kde.org/show_bug.cgi?id=433299 I'm afraid KDE doesn't have any control over the console behavior in VTs, so this issue will have been caused by something somewhere else. I'm pretty sure what happened is that with the newer Plasma version, we switched to Systemd boot by default, and you're running into a change in behavior coming from Systemd. So you have two options: - Disable the systemd boot with `kwriteconfig5 --file startkderc --group General --key systemdBoot false` - Follow up with the Systemd folks about it (In reply to Nate Graham from comment #5) > I'm afraid KDE doesn't have any control over the console behavior in VTs, so > this issue will have been caused by something somewhere else. I'm pretty > sure what happened is that with the newer Plasma version, we switched to > Systemd boot by default, and you're running into a change in behavior coming > from Systemd. So you have two options: > - Disable the systemd boot with `kwriteconfig5 --file startkderc --group > General --key systemdBoot false` > - Follow up with the Systemd folks about it I use systemdBoot false` in startkderc In that case I have no idea what it could be, but maybe there's a slim chance KWin is involved here and could have caused this issue. Actually, let me ask for clarification on something. Are you using virtual terminals for this? Or are you just running `mc` in a regular terminal app like Konsole? (In reply to Nate Graham from comment #8) > Actually, let me ask for clarification on something. Are you using virtual > terminals for this? Or are you just running `mc` in a regular terminal app > like Konsole? I experience this bug in any terminal app running under kde. I use konsole exclusively but it happens in xterm or any other terminal app. It doesn't happen in xfce or icewm or a virtual console, it only happens under kde and the change in behavior causes scripts executed in the terminal app to be restricted to a private shell and this causes the mc shell script to fail. Another consequence is: https://bugzilla.suse.com/show_bug.cgi?id=1213156 Probably something about the environment variables set during plasmashell's startup is triggering this. Can you try to figure out which environment variable is the cause? (In reply to Nate Graham from comment #10) > Probably something about the environment variables set during plasmashell's > startup is triggering this. Can you try to figure out which environment > variable is the cause? I'm not really sure how systemd actually affects the shell to cause this, seems like a security measure to prevent malicious scripts from executing. I compared the output of "set" between the non systemd startup and the systemd startup and searched through kernel settings but I couldn't find anything. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! Info for needinfo in comment 11 If this is still happening in Plasma 6.3, can you try in a new clean user account to rule out any of your customizations or user-specific environment variables being at play? If it works there, hopefully we can narrow down which specific thing causes it, and then we can dig into whether our handling of it is a bug or not. Thanks! 🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone! (In reply to Nate Graham from comment #14) > If this is still happening in Plasma 6.3, can you try in a new clean user > account to rule out any of your customizations or user-specific environment > variables being at play? If it works there, hopefully we can narrow down > which specific thing causes it, and then we can dig into whether our > handling of it is a bug or not. Thanks! Sorry for the delay, I've openSUSE Tumbleweed with plasma6 and Leap:15.6 with plasma5 sharing the same home partition. The workaround that still works on leap but no longer fixes Tumbleweed was to start mc.sh in the current shell with bash command ".". The best test to explain the problem is a script in your home directory "echo -e "cd bin" > testmc && chmod 0755 testmc" if you execute ./testmc you will remain where you are and if you execute ". testmc" you will change to ~/bin This problem first surfaced in plasma5 and has so many workarounds that it gives me a headache but my mc exits into the directory that I'm in in mc when I exit because I've modified the wrapper script. Unfortunately I don't have time to find the cause in plasma6, in plasma5 I only had to disable systemd boot but it seems like systemd boot can no longer be disabled. mc works for me with the workaround 🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone! |