Bug 522948 - Confirmation dialog for shell script no longer provides "open with <editor>" option next to "launch" and "cancel"
Summary: Confirmation dialog for shell script no longer provides "open with <editor>" ...
Status: RESOLVED UPSTREAM
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (other bugs)
Version First Reported In: 6.28.0
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: KIO Bugs
URL: https://dev.gentoo.org/~asturm/bashsc...
Keywords: regression
: 524488 524548 524560 (view as bug list)
Depends on:
Blocks:
 
Reported: 2026-07-11 21:27 UTC by Andreas Sturmlechner
Modified: 2026-09-10 09:32 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 6.30
Sentry Crash Report:


Attachments
helloworld.sh (permissions: -rwxr--r--) (42 bytes, text/x-shellscript)
2026-07-11 21:27 UTC, Andreas Sturmlechner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Sturmlechner 2026-07-11 21:27:39 UTC
Created attachment 194219 [details]
helloworld.sh (permissions: -rwxr--r--)

- it does so no matter if
  - file extension is .sh or no ext
  - shell script is POSIX or Bourne-Again
  - permissions are -rwxr--r-- or -rwxr-xr-x
  - file is in home folder or somewhere else
- .py (python) scripts are still getting all 3 options as expected (same perms)
- .pl (perl) scripts are still getting all 3 options as expected (same perms)
- right click menu still shows "open with" below "run executable" though
- dolphin *is* set to "always ask" when opening an executable file
- noticed that text/x-shellscript application preference had gotten lost (presumably same update), but re-adding kate didn't change behavior

devspace $URL link shows a screenshot of what I see.

---

Dolphin: 26.04.3
KDE Frameworks: 6.28.0
Qt: Using 6.11.1 and built against 6.11.1
'Gentoo Linux' (Wayland)
Build ABI: x86_64-little_endian-lp64
Kernel: linux 6.12.95-gentoo
Comment 1 Nate Graham 2026-07-11 21:35:24 UTC
I can reproduce this for shell script files, i.e. files named ending with ".sh", ".bash", etc. If I rename one such file to end with ".py", I see the correct dialog.

I think it's erroneously going down the "I'm an executable binary" code path rather than the "I'm an executable text file" code path.

I'll take a look.
Comment 2 David Redondo 2026-07-28 13:24:39 UTC
Maybe related https://gitlab.freedesktop.org/xdg/shared-mime-info/-/commit/41fd0ddee6e37d9789d3d3e9e53d4d72db044429 ?

shared-mime-info release was recently
Comment 3 Andreas Sturmlechner 2026-07-28 20:11:37 UTC
(In reply to David Redondo from comment #2)
> Maybe related
> https://gitlab.freedesktop.org/xdg/shared-mime-info/-/commit/
> 41fd0ddee6e37d9789d3d3e9e53d4d72db044429 ?
> 
> shared-mime-info release was recently

indeed, downgrading from 2.5.1 to 2.4 fixes this.
Comment 4 Nate Graham 2026-07-28 20:34:44 UTC
I've commented there; let's see what happens.
Comment 5 Méven Car 2026-08-10 10:15:11 UTC
Fix proposal: https://invent.kde.org/frameworks/kio/-/merge_requests/2368
Comment 6 Méven 2026-08-10 11:16:15 UTC
Git commit 329e84b859525482a5a293ff8372bef95dc2f644 by Méven Car.
Committed on 10/08/2026 at 10:13.
Pushed by meven into branch 'master'.

openurljob: open a shell script rather than refuse it as a program

shared-mime-info 2.5.1 renamed application/x-shellscript to
text/x-shellscript and left application/x-executable as its only parent,
where a script used to be a kind of text/plain as well.

Being both is how a script was told apart from a binary, so a shell script
now reads as a binary and opening one where running is not allowed ends in
an error rather than in the editor. The same loss took the text editors
away from scripts, so one that nothing else claims is opened with whatever
opens text.
FIXED-IN: 6.30

M  +17   -1    src/gui/openurljob.cpp

https://invent.kde.org/frameworks/kio/-/commit/329e84b859525482a5a293ff8372bef95dc2f644
Comment 7 Antonio Rojas 2026-08-20 14:15:55 UTC
*** Bug 524488 has been marked as a duplicate of this bug. ***
Comment 8 Antonio Rojas 2026-08-21 18:29:55 UTC
*** Bug 524548 has been marked as a duplicate of this bug. ***
Comment 9 Antonio Rojas 2026-08-22 08:45:52 UTC
*** Bug 524560 has been marked as a duplicate of this bug. ***
Comment 10 Andreas Sturmlechner 2026-08-25 20:11:20 UTC
hm, unfortunately, with 

- 329e84b8
- 71fcfa96
- 92594ac3

applied on top of 6.29.0 I can't say that this has fixed the problem for me. It looks the same as with vanilla 6.29.0 still.
Comment 11 Nate Graham 2026-09-01 23:18:51 UTC
Following that patch being merged, I'm seeing everything working properly with git master of Frameworks (well, everything KDE) on KDE Linux.

Is it possible the shared-mime-info change got reverted or patched out on Gentoo, and now that's causing the fix to fail?
Comment 12 Ardith Metz 2026-09-09 20:24:21 UTC
I can confirm kio 6.30 doesn't fix the issue on Arch Linux with shared-mime-info 2.5.1

Arch shared-mime-info package doesn't revert upstream change that cause the original issue.

https://gitlab.archlinux.org/archlinux/packaging/packages/shared-mime-info/-/blob/main/PKGBUILD?ref_type=heads
Comment 13 David Faure 2026-09-10 08:12:01 UTC
Does https://codereview.qt-project.org/c/qt/qtbase/+/765860 fix this?
Comment 14 Andreas Sturmlechner 2026-09-10 09:32:14 UTC
(In reply to David Faure from comment #13)
> Does https://codereview.qt-project.org/c/qt/qtbase/+/765860 fix this?

That fixes it indeed, thanks.