How do I change the click behaviour?

Hello, comunity :grinning_face_with_smiling_eyes:!

I need help for adapting the result of mouse clicking on shell script files to my needs:

  1. Konsole: clicking on shell script files will bring up an error dialog saying For security reasons, launching executables is not allowed in this context., regardless of the the executable bit state. I agree with the error mesage, I don’t want to launch executables by clicking in Konsole. But whatever one’s stance on that, clicking to open an error dialog is clearly not productive. At very least, I’d like the executable bit to be complied with, but I’d very much like to open the editor instead. How do I do this? I know I can use the right-click for this, but my hand is much less precise when right-clicking.
  2. Dolphin:
    • clicking on shell script files with the executable bit enabled launches the shell script with no feedback whatsoever, which is bad UX. But maybe it’s complicated to have the said feedback. Regardless, how do I get feedback in this context?
    • clicking on shell script files with the executable bit disabled opens a warning dialog saying This will start the program:[...] If you do not trust this program. click Cancel. Well, having the the executable bit disabled should already give a hint of how my trust in that particular file. What’s worse, in the context menu or in the Open with settings for shell scripts, what’s shown as the default option is opening in the editor. Launching does not even appear. So, how do I make the (double-)clicking on shell scripts with the executable bit disabled open them in the editor?

Thank you for your patience!

System info:

Operating System: Manjaro Linux 
KDE Plasma Version: 6.7.3
KDE Frameworks Version: 6.28.0
Qt Version: 6.11.1
Kernel Version: 6.18.38-3-MANJARO (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ i3-4170 CPU @ 3.70GHz
Memory: 17 GB of RAM (16.7 GB usable)
Graphics Processor 1: NVIDIA GeForce GT 730/PCIe/SSE2
Graphics Processor 2: NVIDIA GeForce GT 730/PCIe/SSE2
Graphics Processor 3: Unknown

Konsole 26.04.3
Dolphin 26.04.3


I don’t understand why you would click on a file in Konsole… can you explain?

It seems like you’re clicking the file in Dolphin, and KDE’s KIO is preventing Dolphin from directly executing binary files if you double-click them.

You might want to look in settings in Dolphin for opening executable files… maybe you set it to not execute scripts instead of ‘ask’ or ‘run’ them.

Because in Konsole is the output of commands listing files, like grep or find. Basically I’m doing most of the stuff in Konsole. I’m pretty sure it was a time when clicking on a file in Konsole did the default action, which, for me, was opening in the editor.

It’s pretty obvious preventing launching executables it’s a security feature and I don’t want to mess with it. Only I never wanted to launch executables from Konsole. The issue for me is that after some update, Konsole started to try to launch clicked files instead of opening them with the associated program and I don’t know how to revert this behaviour. The irony is that it tries to launch them, then it slaps itself on the wrist because is not secure.

The only setting I found is in Edit profile > Mouse > Miscellaneous > Open files/links by direct click, which is enabled. When disabled, clicking on the file/link does obviously nothing (the right-click/context menu is available regardless of this setting).

To me, Konsole and Dolphin’s behaviours are obviously related, hence a single thread.

Ok, you’re right - I didn’t test it because I don’t usually think to click scripts in Konsole… if I want to run ‘test.sh’ I’ll just type ./test.sh because obviously using konsole we have hands on the keys ready to type already.

You can run scripts via the context menu too. I think the protection against running a script via a left click makes sense, not sure if I’d wanna disable that… you only really discovered it because you were approaching it from a rather novel/unconventional angle of taking your hand off the keys to reach for the mouse and click in the terminal.

Many issues arise from the vast variety of clicking errors in Linux, so this protection is actually quite a good one.

Clicking behavior confused summary

  • System Settings > Workspace > General Behavior > Clicking set to "Selects them (Open by double-clicking instead) *This is ignored by Konsole. Thus, the default clicking action is double-click in Dolphin, single click in Konsole.

  • The behavior for text files is what I would expect: the default clicking action opens it in the associated editor** in both Dolphin and Konsole, the context menu default action is the same as the default clicking action and it can be changed.

  • Default clicking action on executable file (is detected as executable and has the executable bit enabled): Dolphin runs it with no feedback whatsoever, Konsole tries to, then slaps itself on the wrist with a security error. Basically rendering the Konsole default clicking action inoperable.

  • Default clicking action on disabled executable file (is detected as executable, but has the executable bit disabled): Dolphin open a Continue/Cancel dialog for running the executable (it will enable the owner executable bit by itself if you choose “Continue” :scream:), while Konsole will again try to run it, then it will again slap itself on the wrist with a security error. Both behaviors basically will try to nudge you to enable the executable bit, each time you want to open the file. Unless you change the file content and extension :rofl:, because it will be detected as potential executable if it has a ‘.sh’ extension or if has no extension, but it starts with a shebang.

  • Context menu on executable file: in both Dolphin and Konsole the default action is “Run Executable” and it cannot be changed.

  • Context menu on disabled executable file: in both Dolphin and Konsole is the same as for a text file.

So, there is no default clicking action for files detected as executables, unless you enable the executable bit in Dolphin (and then there is no feedback), or mess with the security settings in Konsole.

Ok, it does look like a rather messy edge case in the Plasma UX.

However, we must remember that Context is very important here, and it isn’t reasonable to expect consistency.

Dolphin treats executables as applications - so it tries to run, as a detached background process (so no feedback - expecting a GUI app to spawn a window or something).

For this reason, it’s often a good idea to throw in a notification with any scripts you write.

For example, the script to toggle my phone’s audio on bluetooth includes both a visual and an audible confirmation of success or failure built in. I edited and created some specific sounds which stand out from the system sounds (e.g. the sound for enabling/disabling surround sound is Ubuntu Tomtoms playing either Left/Right for quadrophonic stereo or one drum hit for each, going around all speakers.

 notify "Bluetooth Connected" "$DEVICE_NAME was connected" "$CONNECT_SOUND"

This means even with no audio, I know when the phone’s connected or audio is switched even if I click the script. Every ‘echo’ is (not jokingly) echoed in a ‘notify’ or an audio feedback.

Another workaround is something I did before with a sleep/wake script to run at the end of the day which spawns a konsole window and asks me to specify wake time and possibly a delay before suspending.

Konsole’s context menu actions are plugins that call the same KRun backend as dolphin, but Konsole adds an extra security/PTY check. So if an executable lacks a proper desktop file or GUI binding it won’t run. I guess it’s just not well communicated.

I would agree that to ‘auto-enable’ the +x bit is controversial, to put it kindly.

Thinking about it, perhaps THIS should be regarded as a bug, as an anti-security pattern. Auto-chmod is weird.

Shebang and .sh detection is a MIME thing, OS level and not Plasma specific.

The sane way - in Dolphin, for scripts you didn’t prepare yourself, right click and open in Terminal… don’t double-click.

Double-click is a GUI thing, keep it for the GUI.

In a terminal, then you must simply do ./script to bypass KRun entirely, to get full stdout/stderr and no security nags.

Konsole could use a warning that suggests you use ./ for scripts… maybe another issue to file.

I hadn’t experienced any real pain here, because it’s muscle memory to me now that Double-Click is only for GUI applications and when I have weird extras in the terminal enabling mouse interactions, you’re entering foreign territory that isn’t part of your desktop GUI.

i use the default bash shell with a plasma 5 era konsole and it does not do ANYTHING when click on it with my mouse, text file, shell script or otherwise.

this entire thread is alien to me… konsole is text only and the most i can do with it is highlight and paste.

am i missing something or are you guys both using some exotic feature of plasma that i’ve somehow avoided to date.

Some of my scripts have notify calls and/or guards, but there always be the possibility of clicking on one that does not. Given all the interface emphasis on “executable is dangerous” I find myself confused by the current behavior.

About clicking/double-clicking: I’m sorry I was not clear enough

I’m not doing double-click in Konsole, nor I ask for. Also, I find scrolling lists by mouse and clicking on items quite fit for me, sorry about that, it is hard to teach an old dog new tricks. Also, I would’ve liked to find out standardized workflows like "don’t do this, do that’ in the application documentation - I tend to approach things in a “if it’s not forbidden , then it’s allowed” manner. So, while I’m aware that I can change my workflow to get my desired result, I’m not very happy to have to do it.

Probably this:

No.

However, I do use Konsole and Kitty terminals - and they have slightly differing behaviours.

Here’s an example:

eza --icons --group-directories-first --hyperlink --color=always

the ‘hyperlink’ means that images appear as links, but also the *.sh does…

A single click on links (folders open with Dolphin, Images would open with Gwenview and *.sh is just something I’d never think to click if not having read this post.

when i look at konsole --help there does not seem to be any --hyperlink option.

it must be a new thing for plasma 6

Here, in konsole, I can click Desktop and get it open in Dolphin:

try using eza with the command I supplied and click on links.

i have no need for this… i just didn’t understand what y’all were talking about.

I think OP is just wondering why clicking in their terminal isn’t working the same as the GUI… personally I’m more likely to hit y to call up Yazi if I’m browsing and opening files in the terminal… or just type and autocomplete… both faster than reaching for a mouse.

Please, refrain from out-of-topic replying. This includes “it does not happen to me” or “I am doing this differently” replies bringing nothing useful to the discussion. Even more when the info is already available, like the software versions or

which should suggest that my hand is already on the mouse, thus reaching for a mouse cannot be slower than any typing. Also, the topic is not about deciding if my workflow is allowed/recommended or not. I tried to explain my context, but let’s not divert the thread.

My questions are about clicking in Konsole, or double-clicking (if double-clicking is enabled) in Dolphin on files (I know that those are technically links) that may have the executable bit disabled or enabled and that are detected as potential executables by the system:

  1. Executable bit disabled: what can I do to have the file open in the associated app, instead of trying to launch it? This is the main question.
  2. Executable bit enabled: can I change the default action of launching it to something else, like, say, opening in the editor? I am quite sure that the answer to this one is no, but, hey, KDE made me think it can do anything I can imagine.

in dolphin you can use modifiers to open a file with a different application from the default one.

so for instance you can shift+click on a .sh file to open it in a text editor rather than run it.

i don’t know if this carries over to clicking on items in konsole, but since it’s a built in plasma feature and not a dolphin specific feature, it might.

For the full system, then. System settings > Home > Select files and folders: Click Selects them.

Hopefully this will apply to all system. I will reply if I find the thing in Konsole and Dolphin specifically.

Go to Settings in Konsole and then click Enable all “Do not Show” messages. This might enable it but it will disable it for me

Thank you all for your suggestions. Unfortunately, none is working.
The only modifier modifying anything is Alt, which makes double-clicking a file in Dolphin open its properties (same as the Properties context menu item). I did not perceive any change with Shift and Ctrl.

This just sets single-click or double-click as the default action and it was already stated:

This one:

is probably this

I am now keeping a minimal test bed with 8 files containing these:

#!/bin/bash
# file: exe-off-empty-no-ext-with-shebang

# file: exe-off-empty-sh-ext--no-shebang.sh

# file: exe-off-no-ext-no-shebang

notify-send --app-name="${0##*/}" "Default Action Test" "no extension, no shebang"

#!/bin/bash
# exe-off-sh-ext-with-shebang.sh

notify-send --app-name="${0##*/}" "Default Action Test" "'sh' extension, with shebang"

#!/bin/bash
# file: exe-on-empty-no-ext-with-shebang

# file: exe-on-empty-sh-ext--no-shebang.sh

# file: exe-on-no-ext-no-shebang

notify-send --app-name="${0##*/}" "Default Action Test" "no extension, no shebang"
#!/bin/bash
# file: exe-on-sh-ext-with-shebang.sh

notify-send --app-name="${0##*/}" "Default Action Test" "'sh' extension, with shebang"

As you can see the first 4 are variations with the executable bit disabled on having or not a file extension and/or a shebang. The last 4 mirror them, but with the executable bit enabled.

Please use them to test your solutions.

i misremembered this feature since i don’t have it yet, but the implementation is discussed here

  • you can open a file with the 2nd application on the file association list using middle click

  • you can open a file with the 3rd application on the list using Shift + middle click

not sure if this helps you, but that feature is what i was trying to communicate and setting the file associations you want for the 1st, 2nd and 3rd position gives you some options you may not have been aware of.