strange escape handling in Exec line of .desktop files

Bug #335712 reported by Steve Langasek
4
Affects Status Importance Assigned to Milestone
gnome-desktop (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

Given a .desktop file with the following line:

  Exec=env WINEPREFIX="/home/vorlon/.wine" wine "C:\\comlogo\\Comlogo.exe" c:\\comlogo\\demo\\kidspac.lgp

clicking on it causes the following command to be executed:

  wine "C:\comlogo\Comlogo.exe" c:comlogodemokidspac.lgp

I.e., the backslashes in the quoted string are reduced once, but the backslashes in the unquoted string are reduced twice, resulting in an error when running the command.

I can't see any reason why the backslashes should be collapsed twice when not quoted; this is definitely not consistent with how this command is interpreted by a shell.

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

This is almost certainly caused by glib, so re-assigning.

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

And after looking at it again, I am almost certainly wrong. Re-assinging back.

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

I've recreated this now. Steve, did you manually edit the Exec line of the desktop file? The only reason I ask is that I just created a fresh desktop file using gnome-desktop-item-edit, and entered the Exec line that you quoted, but gnome-desktop-item-edit doubled the number of backslashes in the unquoted string, so the desktop file actually worked correctly

Changed in gnome-desktop:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Chris Coulson (chrisccoulson) wrote :

FYI, after creating the desktop file with gnome-desktop-item-edit and the string you quoted above, my desktop file actually contained the following exec line:

Exec=env WINEPREFIX="/home/vorlon/.wine" wine "C:\\\\comlogo\\\\Comlogo.exe" c:\\\\comlogo\\\\demo\\\\kidspac.lgp

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 335712] Re: strange escape handling in Exec line of .desktop files

On Thu, Mar 12, 2009 at 10:58:29PM -0000, Chris Coulson wrote:
> I've recreated this now. Steve, did you manually edit the Exec line of
> the desktop file?

No, it was auto-generated by wine.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
wild.ideas (wild-ideas) wrote :

I'm experiencing the same problem, and tracked it down to the 'exec' line in the '.desktop' file. I'm seeing the same behavior, whether I use the menu editor to create the '.desktop' file, or if I hand-edit the file to modify the 'exec' line.

Ironically, I ran into this with Wine, just as the original reporter did. I'm trying to launch 'notepad' in Wine, giving it a path to a document to open.

I've determined that the GUI editor seems to automatically double my backslash characters. Per the Wine documentation (and special character escaping rules), I expected to have to double the backslashes when I created the menu property. However, the GUI editor seems to handle this for me.

The problem is THIS: When 'exec' execs the command, the parser is stripping out ALL of the backslash characters -- no matter how many you have in the line. And it doesn't seem to matter how you escape the line with various quotings & backslashing -- it still assiduously finds and strips them all out.

If I copy the line and paste it into a terminal -- with the backslashes appropriately doubled -- then the line is parsed and executes correctly, launching 'notepad' with the text file displayed. But in the '.desktop' file, the 'exec' command's backslash stripping means there's no apparent way to make this work.

One more thing the development team needs to do: Add a 'help' to explain what's required as far as quoting and escaping special characters when creating a command line. It takes a lot of Googling to find these rules...

Cheers!

Revision history for this message
wild.ideas (wild-ideas) wrote :

AHA!!! It's NOT a bug in the 'exec' parser!!!

I found it... It's a bug in the way the menu editor & Wine create/manage/display the menus. It's not acting consistently!

Here's what's happening: I'm running 64-bit Karmic. I have an application I installed in Wine 1.1.38 called "MyApp". When "MyApp" installs, it (meaning MyApp's installer, Wine, and Ubuntu in some combination unknown to the layman) creates a menu folder entry in 'Applications / Wine / Programs' called "MyApp".

Inside the "MyApp" folder, the install process creates several '.desktop' files for MyApp.exe, a few other associated apps, and entries to run 'notepad' with arguments that are README files.

In my case, one of these 'notepad' launchers works, one doesn't. Examining the two revealed that the one that doesn't work fails only because the README file argument, which contains '\' characters, isn't quoted with double-quotes. The one that works has a quoted argument.

I.e., the 'exec' parser is working properly according to http://library.gnome.org/devel/desktop-entry-spec/ (under "The Exec key"), which states "If an argument contains a reserved character the argument must be quoted."

Here's where it gets weird: When I ran 'System / Preferences / Main Menu' and edited the Properties for the "notepad README" item, I could clearly see the change appear in THIS directory & file:

.local/share/applications/wine-Programs-MyApp-MyApp ReadMe.desktop

by cat'ing the file in a terminal window. My changes appear, and it automatically doubles my backslashes...

However, that's NOT the '.desktop' file that's launching the "notepad README" item!

It turns out that MyApp's installer / Wine / Ubuntu is creating TWO sets of '.desktop' files... And when you attempt to launch a Wine app, it uses THIS directory & file:

.local/share/applications/wine/Programs/MyApp/MyApp ReadMe.desktop

which is NOT edited by using 'System / Preferences / Main Menu'. You have to manually edit this file (using, e.g., 'vi'). And it my case, that amounted to correcting the argument to 'notepad' by enclosing it in double-quotes to meet the rules of the 'exec' key field for '.desktop' files.

Once done, it launched properly from ''Applications / Wine / Programs / MyApp', as expected.

So WHY are two sets of '.desktop' files being created / maintained? That's the bug! It's not the parser for 'exec'.

Oh, and we still need a 'help' for guidance on escaping/quoting special characters... :^)

Revision history for this message
Cefn (6-launchpad-net-cefn-com) wrote :

Yes, please provide information how to escape paths with spaces. There's no example I can find, and it seems impossible to satisfy the parser (I can't make my entry appear at all).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.