Definition of command line in the Exec key

[Роман Чистоходов]

Of course I understand that Exec can't be directly passed to execve. What I
meant is it to do unescaping, unquoting and expanding field codes first and
then pass the resulting array to execve.
I just want spec to be a bit more clear on reasons behind all this
"reserved characters" stuff. It would be less confusing that way.
Whatever intentions the spec authors had when they added these rules, they
should be included in spec too. It's too hard to get it right if
implementer does not understand the reasons of why things're done the way
they're done. It would be also beneficial to have more examples like
"string as written in desktop file" -> "unescaped string" -> "array of
unquoted strings" -> "array of unquoted strings with expanded field codes"
so implementers be sure that they get all these rules correctly.

On Thu, Mar 23, 2017 at 3:24 PM, Simon McVittie <smcv at collabora.com> wrote:

> On Mon, 20 Mar 2017 at 05:09:19 +0300, Роман Чистоходов wrote:
> > Should it be considered shell command line
>
> No, the content of Exec= is not a one-line shell script. If you need
> to use shell constructs like if...fi, ``, ${} then you must invoke a
> shell yourself:
>
>     Exec=sh -c "if foo; then bar; else baz; fi"
>
> > or something that can be called via execve.
>
> You can't directly pass the value of the Exec key to execve, because
> it's a single string and execve wants an array of strings, but it's close.
>
> To parse an Exec value, you must unquote it according to the generic
> .desktop file syntax, then break it into an array at unquoted whitespace,
> then undo shell-style quoting within each entry of that array.
> The desktop entry spec does describe this, although from the perspective
> of a .desktop file author (there are many of those) rather than from the
> perspective of an implementor (there are only a few of those).
> GLib's g_shell_parse_argv() is one common C implementation of those
> operations; there is another in dbus-daemon.
>
> (For a general implementation you also need to expand *field codes* like
> %f,
> some of which expand to more than one argument in the output argv. In GLib
> this is done in a different layer - see GDesktopAppInfo for an
> implementation.)
>
> > Giving that desktop-file-validate does not like unquoted backticks I
> would say
> > the latter, but all this stuff about quotation rules makes me think
> about the
> > former.
> > This is probably due the legacy code that makes behavior of Exec similar
> to the
> > one if this command line was to be run in shell.
>
> It is essentially a subset of /bin/sh syntax. I believe the intention
> is that every Exec value that is valid according to the Desktop Entry
> Specification has the same meaning in /bin/sh and in a spec-compliant
> .desktop file parser. However, many Exec values are not considered valid,
> and would produce different results from g_shell_parse_argv() and a full
> /bin/sh shell; it is probably not considered to be a bug in GLib's
> g_shell_parse_argv(), KDE's equivalent, your equivalent, etc. if they
> produce different results for an invalid .desktop file.
>
>     S
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20170323/41871546/attachment.html>