Desktop Entry Specification needs clarification

[Karl Mikaelsson]

Hi,

While trying to write a desktop file generator and parser that will
follow the Desktop Entry Specification, especially in regards to
quoting, I've run into some issues and inconsistencies with the 
specification that I'd like to get clarified and improved on.

I've run tests with KDE 4.4 and Gnome 2.28 on Fedora 12, to see how
the major implementations of this specifications differ from each other
and the standard.

Quotes are from the latest version of the specification, dated
2008-09-12. I'd like to thank my colleague Pierre Ossman for input on 
the specification and the flaws found.


Possible value types
--------------------

 > Values of type string may contain all ASCII characters except for
 > control characters.

What's the definition of control characters? < 0x20? <= 0x20?

 > The escape sequences \s, \n, \t, \r, and \\ are supported for values
 > of type string and localestring, meaning ASCII space, newline, tab,
 > carriage return, and backslash, respectively.

Is conversion to these escape sequences mandatory or optional? Given
the format of the file, \r, \n, \t and \\ are most likely mandatory to
avoid ambiguities.

Similarly, escaping all spaces is a bit silly and will most likely
cause problems with some parsers as they expect "normal" spaces. The
spec should recommend that \s only be used when absolutely necessary,
which probably only means when it would otherwise be stripped.

How should unknown escape sequences be handled? I.e. does "\k" mean
"\k" or "k"?


Recognized desktop entry keys
-----------------------------

TryExec, Exec and Path have to hold data that is not restricted to the
ASCII character set and hence cannot be of type string. URL probably
qualifies for this as well unless you want to force people to use puny
code and/or URI escaping. Something that gets extra silly when it
comes to file:// URI:s.


The Exec key
------------

 > The name or path of the executable program may not contain the equal
 > sign ("=").

Why not? The spec should handle any valid program name. I also don't
see where this restriction comes from as the equal sign is only used
as delimiter between the key name and value. And since it isn't
allowed in the key name, the first one must be the delimiter and any
subsequent part of the value.

 > Arguments are separated by a space.

Literal space, or also "\s"?

How are multiple spaces treated? Reasonably they are stripped. It
should be possible to specify an empty argument as "" though. Current
implementations strip multiple delimiters, which isn't compliant.


 > If an argument contains a reserved character the argument must be
 > quoted. ... Reserved characters are space (" "), tab, newline...

These overlap with the general escaping rules and as such might not
appear and hence not need quoting. It makes sense though (except for
newline) if the general escaping rules are optional, and this covers
the case where you chose not to apply them.

By the way, why isn't carriage return in the list?

 > Note that the general escape rule for values of type string states
 > that the backslash character can be escaped as ("\\") as well and
 > that this escape rule is applied before the quoting rule. As such,
 > to unambiguously represent a literal backslash character in a quoted
 > argument in a desktop entry file requires the use of four successive
 > backslash characters ("\\\\"). Likewise, a literal dollar sign in a
 > quoted argument in a desktop entry file is unambiguously represented
 > with ("\\$").

This paragraph is internally inconsistent. The first sentence says
that the general escape rule is applied before quoting[1]. This does
not match up the with the last example which would be "$" => "$" =>
"\$". If we apply the quoting first though, we get "$" => "\$" =>
"\\$", which is the end result mentioned.

[1] Is this the rule for all escape rules or just \ => \\?

This chapter should better explain the interaction between its
escaping and the general one. Which is applied first? Or is the end
result guaranteed to be equivalent no matter the order? From a quick
look, that doesn't seem to be the case.

The order of the global escaping first doesn't make as much sense,
given that it describes a transformation from one string to
another. Input to Exec isn't a string though, but a vector. Hence the
Exec rules should be applied first to go from a vector to a string,
and then apply the general escaping rules on that.


' quoting
---------

The KDE 4 version I tested with defaulted to quote a program with 
newlines or spaces in its name with single quotes, instead of double 
quotes mandated by the standard. This can easily be seen by creating a 
file with a newline or space in its name, and selecting that file by 
clicking the browse button in the "Create link to application" dialog. 
Gnome accepts this as well, which leads me to believe that quoting by '' 
should be accepted by the specification.


-- 
Karl Mikaelsson        derfian at cendio.se
System Developer       +46 (0)13-290863
Cendio AB              http://www.cendio.com/