PATCH: Desktop entry spec - Exec key

[Vincent Untz]

Hi,

On lun, 2006-08-07 at 19:38 -0700, Bastian, Waldo wrote:

[...]

> Process safeguard: The review period for this patch ends at Tuesday Aug
> 15. Without substantial opposition/requests for change I will commit the
> patch after the end of the review period.

(One week for a review period looks a bit short to me, especially in
August)

> Description of the patch:
> 
> * Consistent use of "Key" (e.g. the "Exec" key), "argument" (the things
> that eventually get passed on the command line to the executable) and
> "field code" (e.g. "%f")
> 
> * Clarify that %F, %U, %D and %N must/will expand to multiple arguments
> 
> * Re-added %m to the table because it must be processed according to the
> instructions for deprecated field codes.
> 
> * Change wording of the Exec section as follows
> 
> CURRENT:
> 
> List of valid Exec parameter variables
> ======================================
> 
> Each Exec field may take a number of arguments which will be expanded by
> the file manager or program launcher and passed to the program if
> necessary. 
> 
> Literal % characters must be escaped as %%, and adding new format
> characters is not allowed. It's a fatal error to have an Exec field with
> a format character not given in the spec (exception to this are the
> deprecated format characters which can be ignored, that is expanded to
> no parameters, by the implementation). Again for emphasis: nonstandard
> extensions are not allowed here - you must add an X-Foo-Exec field if
> you have nonstandard Exec lines. 
> 
> The escaping of the exec parameters is done in the way the mailcap
> specification describes. Take a look at RFC 1524 for more information. 
> 
> ====
> 
> PROPOSED:
> 
> The Exec key
> ============
> 
> 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?

> 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".

> 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?

> Although the <varname>Exec</varname> key is defined to have a value of
> the type string, which is limited to ASCII characters, field code
> expansion may introduce non-ASCII characters in arguments.
> Implementations must take care that all characters in arguments passed
> to the executable program are properly encoded according to the
> applicable locale setting.
> 
> ====

Thanks for working on this!

Vincent

-- 
Les gens heureux ne sont pas pressés.