PATCH: Desktop entry spec - Exec key

[Bastian, Waldo]

>> The Exec key must contain a command line. A command line consists of
an
>> executable program optionally followed by one or more arguments. The
>> executable program can either be specified with its full path or with
>> the name of the executable only. If no full path is provided the
>> executable is looked up in the $PATH used by the desktop environment.
>> Arguments are separated by a space. A space can be included into an
>> argument by enclosing the whole argument with either single or double
>> quotes.
>
>What about "application this\ is\ only\ one\ argument"? Is escaping
>spaces (and other characters) okay?

As Francois pointed out, once we allow quotes, we must also allow
escaping of quotes. So I propose that it is either "plain" or "quoted"
and then we still need to define "quoted" a little bit better. 

So I suggest to replace

"A space can be included into an argument by enclosing the whole
argument with either single or double quotes."

with

"
Arguments may be quoted in whole. If an argument contains a reserved
character the argument must be quoted. The rules for quoting of
arguments is also applicable to the executable name or path of the
executable program as provided.

Quoting must be done by enclosing the argument between double quotes and
escaping the double quote character, backtick character ("`"), dollar
sign ("$") and backslash character ("\") by preceding it with an
additional backslash character. Implementations must undo quoting before
expanding field codes and before passing the argument to the executable
program. Reserved characters are space (" "), tab, newline, double
quote, single quote ("'"), greater-than sign (">"), less-than sign
("<"), tilde ("~"), vertical bar ("|"), ampersand ("&"), semicolon
(";"), dollar sign ("$"), asterisk ("*"), question mark ("?"), equal
sign ("="), parenthesis ("(") and (")") and backtick character ("`").

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 ("\\$").
"

Example to illustrate that last paragraph:
Exec=gnome-terminal -t "hello\\" -t "world\\"

And then to answer your question, no, escaping spaces is not ok. It may
work, but will not be guaranteed by the spec with the above proposal.

>> A number of special field codes have been defined which will be
expanded
>> by the file manager or program launcher when encountered in the
command
>> line.
>> Field codes consist of the percentage character ("%") followed by an
>> alpha character. Literal percentage characters must be escaped as %%.
>> Command lines that contain a field code that is not listed in this
>> specification are invalid. Deprecated field codes should be removed
from
>> the command line and ignored. Field codes are expanded only once, the
>> string that is used to replace the field code should not be checked
for
>> field codes itself.
>
>I liked the fact that we said "adding new format characters is not
>allowed".

When I read that part in the current spec I got the impression that it
was aimed primarily at future revisions of the spec, which I considered
odd to put in the spec. But I guess it makes sense to say

"Command lines that contain a field code that is not listed in this
specification are invalid and must not be processed, in particular
implementations may not introduce support for field codes not listed in
this specification. Extensions, if any, should be introduced by means of
a new key."

Ok?

>> Implementations must take care not to expand field codes into
multiple
>> arguments unless explicitly instructed by this specification. This
means
>> that name fields, filenames and other replacements that can contain
>> spaces must be passed as a single argument to the executable program
>> after expansion.
>
>I'm not sure I understand the second sentence: is it only about
>arguments containing spaces (in which case, I believe this is not
>necessary to write this down, altough it's useful to remind it) or is
it
>about passing multiple filenames when there's only %f?

It's a about arguments containing spaces. It's an implementation note.

Cheers,
Waldo