desktop entry spec TryExec key

[Brian J. Tarricone]

On Sat, 24 Mar 2007 19:48:47 +0100, Vincent Untz wrote:

> Le samedi 24 mars 2007, à 10:21, Brian J. Tarricone a écrit :
> > On Sat, 24 Mar 2007 12:18:21 +0100, Vincent Untz wrote:
> > > 
> > > Would this definition fix all the issues?
> > > 
> > > "Path to an executable file on disk used to determine if the
> > > program is actually installed. If the path is not an absolute
> > > path, the file is looked up in the $PATH environment variable. If
> > > the file is not not present or if it is not executable, the entry
> > > may be ignored (not be used in menus, for example)."
> > 
> > Mostly, yes.  I'm still not clear on quoting.  Does TryExec need to
> > follow the same rules with regard to double quotes, backslashes,
> > etc.? Double-quotes seem kinda pointless since TryExec is supposed
> > to just be a file name, so there'd be no reason to quote anything,
> > right?  Would any other forms of escaping be needed or necessary?
> 
> You need to think of TryExec independently of Exec. All the stuff
> about double quotes, escaping, etc. is defined in "The Exec key"
> section, so they don't apply to any other keys.
> 
> The only rule about backslash/escaping that applies to TryExec is what
> is defined in the "Possible value types" section:
> 
> "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."
> 
> (this is obviously not perfect, since it doesn't tell what to do when
> there's a backslash followed by another character, but I've already
> raised this issue a few days ago, and we'll fix it)
> 
> I don't think it's needed to specify that field codes, quoting &
> escaping rules don't apply to TryExec: this part doesn't look
> ambiguous to me in the spec. But if you feel it's still ambiguous in
> the spec, then we should fix in some way.

No, you're right.  Since only Exec has further explanation of how to
interpret it and TryExec doesn't, TryExec should be interpreted just
like any other key of the same string type.  Though I would still
appreciate the addition to the functional interpretation (regarding
PATH, etc.) you propose above.

	-brian