[Feature request] Allow choosing the default shell for new tabs and windows.

[RokeJulianLockhart]

Relevant Problems

I want to utilise pwsh as my default shell. However, chsh -s, as issues/103#issuecomment-67677750 suggests, is inapplicable, because, as PowerShell/PowerShell/issues/9296#issuecomment-657624306 explains, ¹ it's not POSIX compliant. Therefore, it's not safe to utilise as the login shell.

The Desired Solution

Allow me to choose the path of the default shell, irrespective of chsh.

Considered Alternatives

• konsole-25.08.3-1.fc43

• warp-terminal-preview-v0.2025.12.03.08.12.preview_04-1

• rust-alacritty-0.16.1-1.fc43 ²

Context

I want to reproduce bugzilla.redhat.com/show_bug.cgi?id=2420701#c0, to more easily diagnose it.

Footnotes

1. reddit.com/r/linux/comments/1okxryu/comment/ntdkxtm ↩

2. alacritty/alacritty/issues/6746#issuecomment-1519517825 ↩

[tsujan]

Your answer is in #103; isn't it? Set SHELL for qterminal, not for the session.

like konsole-25.08.3-1.fc43 permits …

KDE continues alienating itself from not only standards but also Qt, by doing things in its own way. In contrast, LXQt sticks with Qt. I doubt that it would be a good idea to follow Konsole. After all, QTerminal was forked from Konsole ages ago to get free from KDE.

[RokeJulianLockhart]

@tsujan, wouldn't modifying $Env:SHELL affect more than merely QTerminal?

KDE continues alienating itself from not only standards but also Qt, by doing things in its own way. In contrast, LXQt sticks with Qt.

I don't know of any Qt standards that stipulate that shell defaults should not be superseded at the application level, if that's what you refer to. Do you?

[tsujan]

wouldn't modifying $Env:SHELL affect more than merely QTerminal?

Not if you use it only with qterminal, like SHELL=/usr/bin/fish qterminal

if that's what you refer to. Do you?

No, I meant it in general.

Let me show you just one example — among many — why it isn't wise to follow what KDE/Konsole does. This monstrosity can easily happen when you use Konsole outside KDE:

It doesn't happen with QTerminal or any app that sticks with Qt. KDE devs add more and more options until their apps get out of control, and then they don't care because they test them only under the default KDE session.

In general, adding an option for the sake of showing yet another option isn't good practice, especially when the result can be achieved in other ways.

[RokeJulianLockhart]

Wouldn't modifying $Env:SHELL affect more than merely QTerminal?

Not if you use it only with qterminal, like SHELL=/usr/bin/fish qterminal.

In which case, would adding the ability to define this from QTerminal's GUI be problematic, if you agree that an acceptable implementation method exists? Though, I'll note that unlike setting the shell via what Konsole, Alacritty, and Warp expose, I believe that the environment variable method shall affect anything spawned from QTerminal. ¹ That shan't occur in the aforementioned.

At least, it worked for my original purpose! Thanks.

It doesn't happen with QTerminal or any app that sticks with Qt.

That's a more fundamental problem than per-application configuration options… For the QStyle, as depicted, we need to wait for: ³

• invent.kde.org/plasma/union/-/issues/17

• invent.kde.org/plasma/union/-/issues/37

...although some similar problems are upstream. ⁴

Footnotes

1. chatgpt.com/s/t_693aff89a4708191aa3db17d9dcc0c15 ² ↩

2. c/693afe97-d7e0-8326-88a1-268d804ae9fc ↩

3. discuss.kde.org/t/39063/12 ↩

4. invent.kde.org/frameworks/kirigami/-/merge_requests/976 ↩

[tsujan]

At least, it worked for my original purpose!

Good to know that. Anyway, I'll keep this feature request open — at least for a while…

That's a more fundamental problem than per-application configuration options…

As the author of the Kvantum style, I know where the problem is in KDE. It isn't just in one place: KDE is full of terrible style codes. It was just one example of creating a jungle that couldn't be managed later ;)