Bug 408217 - Switching profile does not execute the custom command
Summary: Switching profile does not execute the custom command
Status: REOPENED
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: 19.04.1
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
: 415355 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-06-02 16:42 UTC by cygx1xue
Modified: 2019-12-21 17:47 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description cygx1xue 2019-06-02 16:42:03 UTC
SUMMARY
Konsole switch profile from gui only change termial theme but not excute the customed command.

STEPS TO REPRODUCE
1. Open Konsole.
2. Click Settings-> Switch Profile -> switch any profile other than the default one (for instance "Root Shell").

OBSERVED RESULT

Knosole only change the theme, but doesn't run the command. "Root Shell" as a exapmple, Konsole doesn't not run "su-".

EXPECTED RESULT

Konsole should change the theme and run command once people change profile from GUI.

However, if you create a shortcut icon/application starter for different profiles, it works flawlessly.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Alexandr Zamaraev (aka Tonal) 2019-06-03 04:46:47 UTC
see also https://bugs.kde.org/show_bug.cgi?id=407076
Comment 2 Achim Bohnet 2019-06-03 09:44:03 UTC
Hi,
AFAIR this behaviour is not new.  That's the way konsole treated the switch-profile as long as I can remember.

When one replaces the command too, then switch-profile would be identical to new-tab (except that it closes the first the current tab).

In my opinions _if_ this behaviour change is implemented then it's better called replace-tab.
Comment 3 Darin McBride 2019-07-06 14:11:03 UTC
(In reply to Achim Bohnet from comment #2)
> Hi,
> AFAIR this behaviour is not new.  That's the way konsole treated the
> switch-profile as long as I can remember.

Prior to https://bugs.kde.org/show_bug.cgi?id=405930, if I used the keyboard shortcut, it would properly create a new tab.  Switching an existing tab to a new process makes no sense to me.

Also, if I use the switch-profile like the way it is now, whether keyboard or menu, and then restart KDE such that that konsole gets restarted, then that tab has the theme AND runs the command, which is different behaviour. I'd say that it's far more broken now than it was before that "fix".

The only way I can see to salvage the difference between "switch profile" and "new tab -> profile" is to separate out *theme* from command/profile. That is, everything under "Settings" changes from "profile" to "theme". There is no command or current directory associated with a theme. The entire "General" tab in profiles would be removed.

And then a new configuration, say "template", would exist that would have that "General" tab that just got removed, plus a link to an existing "theme". (Perhaps the ability to create a new theme at the same time would be there, doesn't matter to me.)

Both themes and templates can have keyboard shortcuts. I would personally never use the shortcut for the theme, but that doesn't mean others wouldn't.

On re-startup, konsole would have to know what template and theme each tab had, and apply as appropriate.

That's the salvage. Otherwise, I would simply move the whole profile thing to be starting new tabs. Because as long as a command exists there, which is the sole reason why I use profiles in the first place, switching a tab to a profile without running the command specified is inherently broken.
Comment 4 Achim Bohnet 2019-07-07 09:19:06 UTC
I completely agree with Darin.  Great summary and suggestion to fix the regression introduced in  #405930, that damaged suddenly my/our workflow.

+1 to associate the shortcuts with 'new-tab'.
Comment 5 Kurt Hindenburg 2019-07-12 03:00:48 UTC
This is a bug in the "Switch" that it doesn't run the Command.  So I'll leave this open for that.  The shortcut issue will create new tabs in 19.08 as they did in 18.12
Comment 6 Łukasz Ligowski 2019-09-08 20:47:29 UTC
This broken my workflow as well. Would be happy if previous behavior is restored.

Darin suggestion on fix is spot on.
Comment 7 Wolfgang Bauer 2019-09-09 05:44:03 UTC
(In reply to Łukasz Ligowski from comment #6)
> This broken my workflow as well. Would be happy if previous behavior is
> restored.
The previous behavior has been restored already in 19.08.

https://cgit.kde.org/konsole.git/commit/?h=Applications/19.08&id=a1b64d7956485c6358bd2cccabde3843c1d314eb
Comment 8 Wolfgang Bauer 2019-12-20 10:05:22 UTC
*** Bug 415355 has been marked as a duplicate of this bug. ***
Comment 9 Peter Tselios 2019-12-20 13:08:39 UTC
Darin comment covered my wishes!
As a side note, for anyone looking at this bug: 
The current workaround (not with keyboard, but at least it's less painful) is to open a new Tab from the File Menu:

File --> New Tab --> <Select the profile> you wish
Comment 10 Peter Tselios 2019-12-20 13:11:08 UTC
(In reply to Achim Bohnet from comment #2)
> Hi,
> AFAIR this behaviour is not new.  That's the way konsole treated the
> switch-profile as long as I can remember.
> 
> When one replaces the command too, then switch-profile would be identical to
> new-tab (except that it closes the first the current tab).
> 
> In my opinions _if_ this behaviour change is implemented then it's better
> called replace-tab.

I use KDE since 1.x and at least with Fedora and Suse/openSUSE it was never the case. I even had scripts in the past to create profiles for the servers of a new project etc.
Comment 11 Darin McBride 2019-12-21 00:13:41 UTC
I can confirm the old behaviour has been restored - if you're on a distro that's not carrying KDE apps 19.08.3+ (maybe earlier), then you'll have to wait until the distro makes available the upgrade.  (Which is why these regressions are so painful - it can take a long time for some distros, especially the LTS releases, to get the fixes.)

However, I thank the developers for fixing it. It's really appreciated and helpful.
Comment 12 Ahmad Samir 2019-12-21 08:42:15 UTC
(In reply to Darin McBride from comment #11)
> I can confirm the old behaviour has been restored - if you're on a distro
> that's not carrying KDE apps 19.08.3+ (maybe earlier), then you'll have to
> wait until the distro makes available the upgrade.  (Which is why these
> regressions are so painful - it can take a long time for some distros,
> especially the LTS releases, to get the fixes.)
> 
> However, I thank the developers for fixing it. It's really appreciated and
> helpful.

You could take the link to the commit that fixed the issue (from comment#7), and file a bug report in your distro's bugzilla asking to backport the fix, they'll consider the patch and see if it can be easily backported or if it's more prudent to wait till the next stable release, usually it's the former :)
Comment 13 Martin Schnitkemper 2019-12-21 10:09:47 UTC
I am not sure if it is the same problem: since version 19.12.0 I am no longer able to connect to a remote host, using another profile. For example: I have a profile and in the settings I set a commend "ssh root@host".  

Until version 19.08.3 I got then a new tab and connection to the host, i. e. after hitting File --> New Tab --> <Select the profile>.  Now in version 19.12.0 I get only a blank, black screen, neither a prompt or a flasing cursor; nothing.  If I downgrade to version 19.08.3 it works again.

Other commands like "su -" for a root-session are working, and also if I issue a "ssh root@host" on a prompt of a existing session, but can't connect to the host while switching to another profile. 

Platform are the Archlinux packages.
Comment 14 Wolfgang Bauer 2019-12-21 12:02:49 UTC
(In reply to Martin Schnitkemper from comment #13)
> Until version 19.08.3 I got then a new tab and connection to the host, i. e.
> after hitting File --> New Tab --> <Select the profile>.  Now in version
> 19.12.0 I get only a blank, black screen, neither a prompt or a flasing
> cursor; nothing.  If I downgrade to version 19.08.3 it works again.

Maybe a problem with the color scheme?
Might be bug#415242...
Comment 15 Wolfgang Bauer 2019-12-21 12:08:05 UTC
(In reply to Darin McBride from comment #11)
> I can confirm the old behaviour has been restored
That's true, but "Switch profile" still doesn't execute the command. (that's not a regression though, it was already like this in the KDE4 version at least)

As that's what actually has been reported in comment#0, maybe the bug should be reopened?
Comment 16 Wolfgang Bauer 2019-12-21 12:16:09 UTC
PS, the bug report hasn't been closed earlier intentionally:
(In reply to Kurt Hindenburg from comment #5)
> This is a bug in the "Switch" that it doesn't run the Command.  So I'll
> leave this open for that.

Reopening therefore.
Comment 17 Ahmad Samir 2019-12-21 12:50:42 UTC
(In reply to Wolfgang Bauer from comment #16)
> PS, the bug report hasn't been closed earlier intentionally:
> (In reply to Kurt Hindenburg from comment #5)
> > This is a bug in the "Switch" that it doesn't run the Command.  So I'll
> > leave this open for that.
> 
> Reopening therefore.

Ouch. Thanks for fixing my mistake :)
Comment 18 Martin Schnitkemper 2019-12-21 17:45:50 UTC
(In reply to Wolfgang Bauer from comment #14)
> Maybe a problem with the color scheme?
> Might be bug#415242...

Yes, it is as you described.  After I changed the background to a fixed color, all is visible for me.  Hence, it is not a connection problem, it was just the black on black that confused me.

For a workaround I will keep these settings, or try to re-compile using  the given patch.

Sorry for the noise, and thanks for your advice.