Seeking clarification of Desktop Entry Specification
sblachmann at gmail.com
Fri Apr 24 11:44:39 UTC 2020
I have found both kinds of whitespace in desktop entry files. So, as a
practical matter, both SPACEs and TABs need to be filtered out when
reading these files.
On 4/24/20, Stephan Bergmann <sbergman at redhat.com> wrote:
> I have three questions regarding
> (1) #basic-format says "A file is interpreted as a series of lines that
> are separated by linefeed characters." #value-types says "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." Even though the former is about the
> structure of the file itself while the latter is about the encoded
> payload, it is confusing that one talks about "linefeed" while the other
> talks about "newline" and "carriage return". Should "newline" read
> "linefeed" (meaning U+000A LINE FEED) instead?
> (2) #entries says "Space before and after the equals sign should be
> ignored". Does that mean just U+0020 SPACE, or also other kinds of
> white space, like U+0009 CHARACTER TABULATION?
> (3) It is unclear exactly when the escape sequences mentioned in (1)
> need to be used in string/localestring values:
> * "\\" apparently needs to be used at least whenever the following
> character is one of "s", "n", "t", "r", or "\". But what about
> sequences like "\a", does it render the file ill-formed, or is it an
> accepted shortcut for the fully escaped "\\a"?
> * "\n" apparently needs to always be used (at least with the "newline"
> vs. "linefeed" clarification from (1)).
> * "\s" (and maybe also "\t" and "\r"?) apparently needs to be used at
> the very start of a string/localestring value (see (2)). But does it
> also need to be used e.g. at the very end of such a value? (From common
> practice, it appears that it at least doesn't need to be used for a
> space somewhere in the middle of such a value.)
> * What about "\t" and "\r"?
> (These questions occurred to me when doing
> "Properly escape desktop file string values".)
> xdg mailing list
> xdg at lists.freedesktop.org
More information about the xdg