Le vendredi 07 avril 2006 à 10:37 +0200, Francois Gouget a écrit :
Hi,
Vincent Untz wrote:
[...]
Not even. First KDE, at least, lets you specify multiple commands
separated by semi-colon so you could drop the 'sh -c':
Exec=/usr/X11R6/bin/xeyes;/usr/X11R6/bin/xeyes
Wow. Does the spec allow this?
Ok, I've found it again:
* the Desktop Entry Specification says:
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s03.html
Some keys can have multiple values; these should be separated by a
semicolon. Those keys which have several values should have a
semicolon as the trailing character. Semicolons in these values need
to be escaped using \;.
In practice I find that keys that have several values rarely have a
trailing ';' but that's not relevant here. What's relevant is that it
does not say that regular strings are not allowed to contain a
semi-colon. On the contrary:
* the Desktop Entry Specification says that the Exec field value is
'string'.
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s04.html
If you look closely at the table, you'll notice that some keys have
string(s) for type. My interpretation is that only those keys can have
separate values. But as you point you, this is not really relevant here.
and
Values of type string may contain all ASCII characters except for
control characters.
So there is no restriction about ';', '|', '', etc.
Right. And why should there be? If I want to create a launcher to open
the Ilovesemicolons;;;.txt with gvim, then why not? The alternative is
to escape the semicolons (so I'd have to put gvim Ilovesemicolons\;\;
\;.txt). A better example might MomDad.txt.
* finally, about the Exec field it says:
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
The escaping of the exec parameters is done in the way the mailcap
specification describes. Take a look at RFC 1524 for more
information.
* so I looked at RFC 1524 but I did not find the word 'escap*'
anywhere in it. However I believe that what the Desktop Entry
Specification meant was that the 'Semantics of executable commands'
section applies to the Exec field. That section says:
http://www.ietf.org/rfc/rfc1524.txt
On a UNIX system, such commands will each be a full shell command
line, including the path name for a program and its arguments.
(Because of differences in shells and the implementation and behavior
of the same shell from one system to another, it is specified that
the command line be intended as input to the Bourne shell, i.e., that
it is implicitly preceded by /bin/sh -c on the command line.)
Indeed. So this is legal for RFC1524.
So from that I deduce that it is legal to use the following in the Exec
field:
Exec=command1;command2 || command3
And that it will behave like
sh -c command1;command2 || command3
But I might be wrong in how I understand the RFC 1524 to apply to the
Desktop Entry Specification. It is quite ambiguous there. In particular
the 'Semantics of executable commands' also says that if there is no
'%s' on the command line, then the content of the file will be passed
through stdin and I doubt that part to apply to the Desktop Entry
Specification...
I really think we should work on fixing this: it shouldn't be ambiguous
at all.
My main issue about making it legal to use the shell syntax here is that
some users with no shell knowledge will create launchers and wonder why
it does not work. And I don't think we should force people who don't
know about the shell to learn all this. On the other hand, people
wanting to achieve this and who realize it doesn't work should be
knowledgeable enough to put use sh -c.
However, we already force people to know that they should use escape
spaces...
Vincent
--
Les gens heureux ne sont pas pressés.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
