KDE Utils: new.exec, shell-exec (for ENTER & click on executables)

[This post includes some test data showing what's wrong in KDE and a peek into the configuration files for various file types.]

Let's start with a program that writes programs. This is 'new.exec'.

file: new.exec (executable)
purpose: create a skeleton of a clickable shell program with an 'exec' extension.
Temporarily install it right where you are (see 'new.symlink' in previous KDE Utils) and to test it, type
[That's an incorrect usage, but legal and adequate for a quick test.]

It should create a program named test.exec.

Click on test.exec and see if it does anything as-is. If not, that is; if it opens in a text editor or tries to play in amarok (which hasn't happened on my system yet but I've seen others posting some pretty strange effects like opening binary executables as image files...) or something like that? Then it's not working.

Also try highlighting it and press ENTER. It should still run correctly.

Open it with a text editor (on purpose) and see what it should do.

When it runs, if it shows the "done" message, delete test.exec and you're alread good to go. You can install it per other "new.*" functions and it will show in 'new.listall' with the others, if you want this utility.

Alas. It did NOT work on my KDE and it may not work on yours. But all is not lost, my fellow Computer Mad Scientists.

*** WARNING: EXPERIMENTAL. You may want to test this on a throw-away user before using this procedure. [On Kubuntu the process is similar but some extra steps may be required to get PATH and LD_LIBRARY_PATH full benefits of this feature.]

The first programable half of the openSUSE (and other?) solution is this.

file: shell-exec (executable)
purpose: iron out mime-type handling inconsistencies in newer KDE
versions.
Additional filtering and testing of file types and extenstions is up to you. All we do here is unbreak old code and restore functionality lost in newer KDE systems.

Leave the test code in it so you can tell when it's running and when it's not. Also the diagnostics may give you some clues as to what's getting messed up if even this doesn't work for your system.

Now if you haven't backed up your HOME/.kde4/share folder yet. Do it now just for good measure (it's not affected by this experiment). And there's another folder you might want to back up too.
Got browse yet? Let's go take a look.
You may see several *.deskop files, some of which may appear to be duplicates, some you may not want, etc. Before you delete anything, though, let's look at the master file that uses these desktop files.

Open mimeapps.list with a text editor.

See anything you wanted to get rid of but couldn't? You can do it there. Also remove the named desktop files you may want to remove from your file associations but couldn't find to delete when we use filet association menus, and (at least on my system) the changes will take effect immediately.

But take a look at a desktop file in an editor and see how they are written.

Our problem with KDE is in regard to two types of files which are these:
And two methods of opening them which are these:
In your systemsettings (from the commandline or from the main menu it may be called "Configure Desktop" or "Personal Settings") find type 'x-executable'. It's in the "applications" node.

Don't set a filename pattern for x-executable. That entry field is probably clear already, but if it's not, remove the pattern string but add our new "shell-exec" as the application to open this type with in 'application preference'.

Apply and close the settings manager.

If you did this with a new user, the 'applications' folder under HOME/.local/share now exists and the shell-exec.destkip file and mimeapps.list files are in there.

At this point, if your PATH and LD_LIBRARY_PATH are set in your HOME/.bashrc file even binary executables linked to libraries in your HOME folder should run. (This is important for developers and testers.) If not set at least your path and logout and back in to make sure it's set at login time.

Notice that executables now run with shell-exec when you highlight them and press ENTER, but they run when clicked by some other means. We can tell because of the test code in shell-exec. Also, for kubuntu, to run the executables you may need to right-click and select 'shell-exec' to open the binary with it. I have not gotten it to work as the default in kubuntu yet.

You can skip this 'testing' section if you like. I just did it to PROVE that something is screwy here.

[Note. your results may differ from mine below because... well... KDE is haunted. Didn't you know that? Different things happen if stuff is set up in different orders, but the final setup, whether done automatically or by hand will finally get KDE to work as is should, as it used to, in a predictable user-controllable manner.]

The important data here is.

Code:

binaries | open with
  click [unknown]
  ENTER [shell-exec]

Repeat the test with test.exec (dolphin)
  click [unknown]
  ENTER [shell-exec]

Repeat the test with test.exec (konqueror) 
  click [unknown]
  ENTER [kwrite]

This tells us that before we set up an association for shell scripts they DO run even before we explicitly set up an association to run them, at least when they are clicked.

But what about the x-shellscript types?

Will they run (behind our backs) by either method? Copy test.exex to test.sh and it now matches the pattern for x-shellscript type in the file association menu.

Code:

Repeat the test with test.sh (dolphin)
  click [unknown]
  ENTER [shell-exec]

Repeat the test with test.sh (konqueror)
  click [unknown]
  ENTER [kwrite]

Here's what we have then.

Code:

        |  clicked  |   ENTER key (dolphin/konqueror)
          ----------------------
*.exec  |  GHOSTS?  |   shell-exec / kwrite
*.sh    |  GHOSTS?  |   shell-exec / kwrite
binary  |  GHOSTS?  |   shell-exec / (untested*)

[A member of Linux Questions recently wrote about a problem he had which at one point included a problem like his binaries opening as image files. Do you believe it? I sure do!]

Using the linux xdg-mime program we can see what the system (? which system ?) thinks each file type is by using

Code:

xdg-mime query filetype <filename>

It says my shell-exec program is: application/x-shellscript as are other *.sh files
It says my test.exec program is: application/x-shellscript
It says my find-deps program is: application/x-executable

All of the above are correct. So then what's wrong with KDE?

-------------

In order to get konqueror and dolphin in step we will also need to add shell-exec to open mime type x-shellscript (if it wasn't added automatically -- don't ask me, I just work here) Add it to the file associations list for type x-shellscript.

Now everythiing is in sync between dolphin and konqueror, between click and ENTER, and between kde and kde.

:-)

If test.exec works now, you can remove it and also test.sh and install new.exec in your HOME/bin/src/misc pile with the other micro programs in there or wherever you keep your shell program sources. And don't forget to 'new.symlink' it for it's new location.

Same with the 'shell-exec' utility. Remove the test code from the body of the script or add filters to prohibit certain file extensions from running (which may be what KDE was trying to do) when you're done playing with it.

The command 'edit ~/bin/shell-exec' should get you there no matter where you installed the program itself.

Or not. It's up to you but these things are very easy to uninstall and do not require any special privileges to install/uninstall. In fact we don't WANT special privileges here. These are our own private 'executable' snippets collections.

See previous KDE Utils posts for how and why we install/uninstall this way and to get a few gizmos you might find interesting.

:-)

If you think I should be writing to KDE about this, I don't agree to their privacy policy regarding my mailbox address but feel free to forward it to anyone you like. Furthermore, I don't think a bug report on this stuff should even be necessary. Isn't anyone that's developing this stuff using the systems they are developing? Many of these problems aren't exactly subtle.

Note: I repeated the above for a brand new user. Here are the files generated.

file:HOME/.local/share/applications/mimeapps.list
file: HOME/.local/share/applications/shell-exec.desktop
I did NOT set the file association for x-shellscript but those run properly for a brand new user while they did not run properly until the association was set manually for my old user.

This is just plain screwy.

But we're all Computer Mad Scientists around here, right? So all's well that ends well.

:-)