Re: Syntax regarding "Exec" instruction in .desktop files
On Mon, 22 Jun 2020 l0f4r0@tuta.io wrote:
Hi davidson,
I share your great answer (see below) with the whole list as I think
your explanations are very didactic, relevant and could be
beneficial to anyone.
I've just tested and it works so thank you very much :)
Lol. Good news! It is good to learn about empirical results.
If I have well understood, my issue was that I've mixed up reserved
characters with distinguished ones, right?
That is what it looked like to me.
The piece of the specification that you posted "distinguished" the
four anonymously, insisting they all four had to receive special
treatment, but gave their class no distinctive name.
By the way, I think it is interesting that bash(1) also explains (in a
paragraph[1] under the section "QUOTING") that inside double quotes,
those same four characters
$ ` \ "
are exceptional, being the only characters whose literal value is not
preserved between a pair of double quotes (assuming either posix mode
or disabled history expansion).[2]
I suspect that putting together the details that give rise to this
coincidence would be cool to understand. I lack that understanding.
But even with little understanding, it is now easier to remember which
characters bash does not remove special meaning from inside double
quotes. (It is like with people: after you know like fifty other
things about them, it becomes easier to remember what their name is.)
So if I sum up, here is the logic:
* As soon as there is at least one *reserved* characters (like
[SPACE] [TAB] [NEWLINE] " ' \ > < ~ | & ; $ * ? # ( ))
Also, backtick.
in an argument, one needs to escape the whole argument
* Argument escaping is done by adding double quotes around it and
prefixing each *distinguished* characters (like " ` $ \) with a \
* Reserved characters must be escaped individually only if they must
lose their specific meaning and be interpreted litterally
Your breakdown of the escape of reserved characters paints a helpful
sequence of operations for me:
* Escaping reserved characters is done by prefixing them with a \
but as the argument needs quoting, the extra \ itself must be
prefixed by a leading \ so a litteral $ becomes \\$, a \ becomes
\\\\, & becomes \\& and so on...
Also, the link Greg posted to the Desktop Entry Specification[3]
includes stuff about field codes that wasn't in the OP excerpt.
A selective excerpt in OP was natural enough, since the specific
example in OP appears to contain no field codes.
But appearances might be deceptive, and if I were considering putting
complex stuff (or even simple stuff) in the Exec field, I would
examine it all very carefully. There are land mines in there:
Field codes must not be used inside a quoted argument, the result
of field code expansion inside a quoted argument is undefined.
And not just the field codes the spec lists an interpretation for;
*any* alphabetic character immediately preceded by an unescaped '%'
character IS A FIELD CODE, and hence a potential land mine, according
to the spec. (And '%' is escaped in a way not like other characters,
because it is after all in a class by itself, and so on...)
Am I correct please?
In the words of deloptes[4]:
Believe you do in the church, not infront of the computer, when we
see the output we can conclude ourself.
Thanks a lot!
That is mutual.
NOTES and REFERENCES
1. From bash(1):
QUOTING
[...]
Enclosing characters in double quotes preserves the literal value
of all characters within the quotes, with the exception of
$ ` \
and, when history expansion is enabled,
!
When the shell is in posix mode, the ! has no special meaning
within double quotes, even when history expansion is enabled. The
characters $ and ` retain their special meaning within double
quotes. The backslash retains its special meaning only when
followed by one of the following characters: $, `, ", \, or
<newline>. A double quote may be quoted within double quotes by
preceding it with a backslash. If enabled, history expansion will
be performed unless an ! appearing in double quotes is escaped
using a backslash. The backslash preceding the ! is not removed.
[...]
2. You might need to squint a little, to see why I include the double
quote character with the other three here. Also, in the case of
double quoted strings in bash (as distinguished from the case of a
desktop entry Exec value) it looks like the backslash is only
special in that context when it is "doing some important
backslashing". That is, when it isn't escaping a "live" special
character, a backslash is just a literal backslash, inside double
quotes in bash.
3. Desktop Entry Specification, "The Exec Key"
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s07.html
4. 23 Jan 2017, deloptes to debian-user
https://lists.debian.org/msgid-search/o64ag3$iq2$1@blaine.gmane.org
--
Firstly, you must always implicitly obey orders, without attempting to
form any opinion of your own respecting their propriety. Secondly, you
must consider every man your enemy who speaks ill of your king; and
thirdly, you must hate a Frenchman, as you do the devil. --H. Nelson
Reply to: