Is that true? All relevant scripts should have the proper shebang
#!/usr/bin/bash
or an equivalent. I doubt that KDE relies on the login shell of the user (as long as it is a POSIX compatible shell)
Its been mentioned more than once .. and I know on some other distros (like Manjaro) they learned this the hard way after trying to bluntly change the login shell first.
Other examples include Gentooās warning about fish
(which can more or less be extended to any non-bash-compatible or just non-POSIX compliant shells)
I have seen that and yet I have used KDE with zsh as login shell for quite some time in the past.
The text you have shared makes some odd statements. E.g.
Changing the default shell (especially to a non POSIX or Bash compatible one) might have unintended consequences as some scripts relying on Bash compatibility might not work anymore.
That should not be a problem as long as the scripts have the proper shebang.
Issues can arise if you use a non POSIX compatible shell like fish because it does not source /etc/profile. And /etc/profile might contain important environment variables from the distro. But that is not the case for zsh.
zsh might be close enough to work for most things but it is not POSIX compliant either.
I might guess that anyone using zsh as login shell with plasma is either lucky .. or maybe someone over at plasma happens to use zsh now because a few years ago it definitely would not work.
While doing some quick searching I found another real-world example, though it is fish again.
My suggestion will continue to be to not change the login shell while using Plasma.
1 Like
As I said.
fish has a different way to set environment variables.
the normal way with bash or zsh is:
export VARIABLE="value"
in fish it is
set +x VARIABLE value
Therefore fish can not source /etc/profile and such.
Manjaro still has zsh as the default shell. I just installed their newest KDE branch to confirm that.
Sure it is not the Profile method alluded to above (with a read-only āBuilt-inā that is bash) ?
Iām with mbod on this, the only scripts that would fail would be those by lazy writers who donāt properly detail which scripting language itās written in (the 'shebang referred to). Otherwise they run with the shell noted in the script. Those eleven characters (typically) should be required on every script!
Shebangs arent really the only issue.
At best we have established that certainly at least some shells do not work well as a login shell in general - and things like Plasma and SDDM in particular. Maybe zsh is one of those and maybe its not. I still think setting your login shell to anything non-POSIX is a bad idea .. and zsh is not POSIX.
The other point is - when using Plasma+Konsole .. it does not matter. You still need to configure your desired shell using the Profiles, so trying to go about it using chsh is still the wrong approach.
Furthermore .. if you can configure your desired shell using the settings in your terminal emulator and you dont have a good justified reason to go further then shouldnt you use that?
Compiled programs should not be affected other than with regards to environmental variables that may or may not be set. It may require customization, and thus may not work by default (pretty rare actually).
A shell environment you feel comfortable with can make a great difference in console actions (like recovery). And in fact, the bourne shell (sh) is the original shell that everything was originally written as a standard, bourne-again shell (bash) intends to be fully compliant to that standard and is the āstand-inā in GNU based systems.
In my opinion, graphical tools shouldnāt be set by default to override your own $SHELL. It should be an option (which is different than a default). But thatās just an opinion, not a fact 
1 Like
I think this discussion should go the other way round. If Plasma or SDDM have a hard dependency on bash they need to make sure that they source all relevant script with bash (incl. /etc/profile and such).
It is not the users fault if she picks zsh as the login shell. If plasma or sddm dont like zsh it should at least be stated in the documentation that only bash is supported. But even then, I would consider this a bug in sddm / plasma.
And what about remote login with ssh, console/tty login or if you use xterm? chsh is the way to go if you want to have a consistent user experience.
PS
I have zsh as login shell on all my accounts since many years. During that time I heavily used kde and xfce without any issues. In the meantime I am with gnome and that does not even have an issue with fish as login shell
I respect your opinion.
To be clear my impression is the user is using the root account as his daily driver.
I would use root for limited maintenance, nothing else.
Anything can be made Insecure or dangerous if used improperly. The original poster was asking for guidance, lets focus on that.
Sorry Iām using Alacrity and Kitty in Gnome. From the others feedback it appears my suggestions for changing the default shell affects KDE.
IMHO, I always keep my root account using BASH shell. My personal account I have configured for zsh.
A shell is merely the CLI version of the file-manager. You manipulate the system through it (opening and closing files). it really isnāt any more than that.
It is known there were rare cases of zsh not compatible with certain scripts (donāt remember where Iāve read it), but itās weird SDDM and Plasma are in this situation.
edit: there was a PR to make SDDM zsh and fish compatible in March, but SDDM in the official repos has not been updated.
Build Date : Wed Jan 8 09:06:50 2025
I guess the solution is to install sddm-git in the AUR.
Iāve never seen a distributed script (from a package) with /bin/zsh or /bin/fish after the shebang, itās usually /bin/sh which is a symlink to /bin/bash.
Right, because sensible people write scripts that are portable (ie std on every install, no weird shells), though if I were writing one for my own use, I might possibly use my preferred shell of the moment.