Certain $HOME/.config/autostart desktop files fail to launch #188

Basic information

TDE version: All
Distribution: All
Hardware: All

Description

This probably has been broken for many years, possibly back to the 3.5 days.

The root cause seems to be the Exec= directive in autostart desktop files is not parsed explicitly. Rather than explicitly execute the entire line in the Exec= entry, the code seems to be based on a presumption of only expecting traditional path strings such as Exec=/usr/local/bin/some_command. This means desktop files with Exec=/bin/sh -c snippets fail to launch.

Searching the web indicates the /bin/sh -c option has been a valid solution for many years.

I have a few such files and this took me a long time to identify. For a long while I thought the files were being ignored. Instead they fail to launch. One clue was in the user .xsession-errors log that TDE was unable to parse the Exec= entries.

Short of updating the code, one work-around is convert the Exec=/bin/sh -c snippets to shell script files. This seems doable except these snippets function as written in other desktop environments. Likely the code in other DEs is executing the entire Exec= line verbatim rather than trying to parse an executable from a path.

My current work-around is I converted my autostart files containing /bin/sh -c snippets into shell script wrappers. Not the end of the world for me and everything remains functional, but the current code is based on flawed presumptions.

Related files seem to include:

tdelibs/tdeinit/autostart.cpp
tdelibs/tdecore/kdesktopfile.cpp
tdelibs/tdeio/tdeio/kservice.cpp

This bug report ties into bug report 2297. I think the NotShowIn issue is caused by code that tries to remove duplicates in the collected list of autostart files. Refer to Comment #2 in bug report 2297. Basically the user XDG files are being removed as duplicates and never get a chance to execute, creating the illusion of being ignored.

Steps to reproduce

In $HOME/.config/autostart, create a desktop file with an Exec=/bin/sh -c snippet. A good test is a string of commands separated by semi-colons and somewhere within the entire string sequence reference a file using a full traditional path. The TDE code then will try to parse the string based on the traditional path and get confused. The user .xsession-errors log should show something related.

Requested Solution

Update the code to perform a readEntry on the Exec= key and just execute the string verbatim. No fancy parsing should be necessary.

I am not configured to test development branches, but if a patch is posted I can back port into the tarballs and test.

## Basic information - TDE version: All - Distribution: All - Hardware: All ## Description This probably has been broken for many years, possibly back to the 3.5 days. The root cause seems to be the **Exec=** directive in autostart desktop files is not parsed explicitly. Rather than explicitly execute the entire line in the **Exec=** entry, the code seems to be based on a presumption of only expecting traditional path strings such as **Exec=/usr/local/bin/some_command**. This means desktop files with **Exec=/bin/sh -c** snippets fail to launch. Searching the web indicates the **/bin/sh -c** option has been a valid solution for many years. I have a few such files and this took me a long time to identify. For a long while I thought the files were being ignored. Instead they fail to launch. One clue was in the user **.xsession-errors** log that TDE was unable to parse the **Exec=** entries. Short of updating the code, one work-around is convert the **Exec=/bin/sh -c** snippets to shell script files. This seems doable except these snippets function as written in other desktop environments. Likely the code in other DEs is executing the entire **Exec=** line verbatim rather than trying to parse an executable from a path. My current work-around is I converted my autostart files containing **/bin/sh -c** snippets into shell script wrappers. Not the end of the world for me and everything remains functional, but the current code is based on flawed presumptions. Related files seem to include: * tdelibs/tdeinit/autostart.cpp * tdelibs/tdecore/kdesktopfile.cpp * tdelibs/tdeio/tdeio/kservice.cpp This bug report ties into [bug report 2297](http://bugs.pearsoncomputing.net/show_bug.cgi?id=2297). I think the **NotShowIn** issue is caused by code that tries to remove duplicates in the collected list of autostart files. Refer to [Comment #2](http://bugs.pearsoncomputing.net/show_bug.cgi?id=2297#c2) in bug report 2297. Basically the user XDG files are being removed as duplicates and never get a chance to execute, creating the illusion of being ignored. ## Steps to reproduce In $HOME/.config/autostart, create a desktop file with an **Exec=/bin/sh -c** snippet. A good test is a string of commands separated by semi-colons and somewhere within the entire string sequence reference a file using a full traditional path. The TDE code then will try to parse the string based on the traditional path and get confused. The user **.xsession-errors** log should show something related. ## Requested Solution Update the code to perform a **readEntry** on the **Exec=** key and just execute the string verbatim. No fancy parsing should be necessary. I am not configured to test development branches, but if a patch is posted I can back port into the tarballs and test.

Hi @Woodsman Darrell,
I tried to simulate the problem creating a desktop file with a Exec=/bin/sh -c... line but I can't reproduce the problem. The file is correctly autostarted and the command executed. Also there are several desktop files in TDE that are autostarted and contain parameters, so not sure what the problem is.
Could you share a test file and list the exact steps/locations to reproduce the problem?

My memory now is fuzzy about this. Despite the Basic Information listing TDE version: All, I was running 14.0.12 at that time. As mentioned in the Description, I converted the problematic files to launch shell scripts that are wrappers to the original commands. I browsed my backups and found the following from some months ago, but I no longer remember if this example was one of the files that failed to launch.

[Desktop Entry]
Comment=Goldendict
Encoding=UTF-8
Exec=/bin/sh -c 'sleep 15; /usr/bin/goldendict'
Name=Goldendict
StartupNotify=false
Terminal=false
Type=Application

Thanks Darrell, I now see where the problem could be.

In $HOME/.config/autostart, create a desktop file with an Exec=/bin/sh -c snippet.

Your scripts are in $HOME/.config/autostart while I placed my script in $HOME/.trinity/Autostart. This is probably why I couldn't replicate the same issue. Will take a second look and also see what we can do to support XDG standard locations for autostart scripts.