<div dir="ltr">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.<div>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. </div><div>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.</div></div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Mar 23, 2017 at 3:24 PM, Simon McVittie <<a href="mailto:smcv@collabora.com" target="_blank">smcv@collabora.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <a href="mailto:xdg@lists.freedesktop.org">xdg@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/xdg" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/xdg</a> </blockquote></div> </div>