<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style> </head> <body dir="ltr"> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div id="appendonsend"></div> <blockquote style="border-left: 3px solid rgb(200, 200, 200); border-top-color: rgb(200, 200, 200); border-right-color: rgb(200, 200, 200); border-bottom-color: rgb(200, 200, 200); padding-left: 1ex; margin-left: 0.8ex; color: rgb(102, 102, 102);"> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)"> (1) #basic-format says "A file is interpreted as a series of lines that<br> </div> <div class="BodyFragment"><font size="2"><span style="font-size:11pt"> <div class="PlainText">are separated by linefeed characters." #value-types says "The escape<br> sequences \s, \n, \t, \r, and \\ are supported for values of type string<br> and localestring, meaning ASCII space, newline, tab, carriage return,<br> and backslash, respectively." Even though the former is about the<br> structure of the file itself while the latter is about the encoded<br> payload, it is confusing that one talks about "linefeed" while the other<br> talks about "newline" and "carriage return". Should "newline" read<br> "linefeed" (meaning U+000A LINE FEED) instead?<br> </div> </span></font></div> </blockquote> <div class="BodyFragment"><font size="2"><span style="font-size:11pt"> <div class="PlainText"><br> </div> <div class="PlainText">When referring to ASCII characters, the names "newline" and "line feed" are synonymous. Both names refer to the character with ASCII code 10 (decimal). Additionally, both names convey the same idea for the action of a line-printer type output device: the print head is advanced to the next line (or, more accurately, the paper is scrolled one line forward). I would be inclined to say that no, the escape sequence '\n' should not be described as referring to a line "feed instead" of a "newline", because '\n' is mnemonic for "newline", and that is the prevailing terminology from C and C-influenced languages, from whence "\n" comes.</div> <div class="PlainText"><br> </div> <div class="PlainText">On the other hand, I take the words "linefeed character" in the description of the format to be chosen intentionally to avoid ambiguity about line termination. Desktop files are specified to consist of lines separated by exactly one linefeed character, regardless of whether that matches the standard line-termination semantics for text files on the host system. This word choice thus minimizes confusion that might otherwise arise around the fact that C and C++, when reading or writing a in text mode, automatically translate between newline (linefeed) characters internally and whatever line termination is locally appropriate externally. The design choice results in the interpretation of .desktop files being insensitive to the conventions of the host environment.</div> <div class="PlainText"><br> </div> <div class="PlainText">Whereas I agree that the disparity in word choice is potentially confusing, I do not think that the wording should be changed in either place. Possibly, however, there is room for a clarifying comment.</div> <div class="PlainText"><br> </div> <div class="PlainText"><br> </div> <blockquote style="border-left: 3px solid rgb(200, 200, 200); border-top-color: rgb(200, 200, 200); border-right-color: rgb(200, 200, 200); border-bottom-color: rgb(200, 200, 200); padding-left: 1ex; margin-left: 0.8ex; color: rgb(102, 102, 102);"> <div class="PlainText">(2) #entries says "Space before and after the equals sign should be<br> ignored". Does that mean just U+0020 SPACE, or also other kinds of<br> white space, like U+0009 CHARACTER TABULATION?</div> </blockquote> <div class="PlainText"> <div class="PlainText"><br> </div> <div class="PlainText">Inasmuch as the wording says simply "space", and not "space characters", I take it to be inclusive of any sequences of U+0020 and / or U+0009 characters. Neither of these may appear in keys, in any case, so the alternative to accepting them both as constituents of "space" is to reject files that use any tabs between key and "=". But I do agree that this is ambiguous and should be cleared up. In particular, since desktop files are encoded in UTF-8, they can also contain any of the relatively many <i>other</i> characters that Unicode categorizes as space characters, and it is unclear whether it is intended that the "space" around '=' signs be inclusive of all these. I suspect that implementations generally accept only U+0020 and U+0009 as "space" in this sense, and maybe U+000D, but it is hard to justify that specific choice from the wording.<br> </div> <div class="PlainText"><br> </div> <div class="PlainText"><br> </div> <blockquote style="border-left: 3px solid rgb(200, 200, 200); border-top-color: rgb(200, 200, 200); border-right-color: rgb(200, 200, 200); border-bottom-color: rgb(200, 200, 200); padding-left: 1ex; margin-left: 0.8ex; color: rgb(102, 102, 102);"> (3) It is unclear exactly when the escape sequences mentioned in (1)<br> need to be used in string/localestring values:<br> <br> * "\\" apparently needs to be used at least whenever the following<br> character is one of "s", "n", "t", "r", or "\". But what about<br> sequences like "\a", does it render the file ill-formed, or is it an<br> accepted shortcut for the fully escaped "\\a"?<br> </blockquote> <div class="PlainText"><br> </div> <div class="PlainText">That is a fair question, and one whose answer I agree is ambiguous. I'm would be inclined to guess that there is a diversity of implementation. It is clear that "\a" is not a recognized escape sequence, as it is not included in the enumeration of those, so what is it? Absent an update to the spec, I would be inclined to say that authors should avoid writing such combinations, and processors should interpret any they encounter as if they were "\\a".<br> </div> <div class="PlainText"><br> </div> <div class="PlainText">Note also that there are special rules for an additional level of quoting for values of "Exec" keys.</div> <div class="PlainText"><br> </div> </div> <blockquote style="border-left: 3px solid rgb(200, 200, 200); border-top-color: rgb(200, 200, 200); border-right-color: rgb(200, 200, 200); border-bottom-color: rgb(200, 200, 200); padding-left: 1ex; margin-left: 0.8ex; color: rgb(102, 102, 102);"> <div class="PlainText">* "\n" apparently needs to always be used (at least with the "newline"<br> vs. "linefeed" clarification from (1)).</div> </blockquote> <div class="PlainText"> <div class="PlainText"><br> </div> <div class="PlainText">If you want a newline (linefeed) character in a value then you must represent it as "\n", because a literal newline would terminate the value.</div> <div class="PlainText"><br> </div> <br> </div> <blockquote style="border-left: 3px solid rgb(200, 200, 200); border-top-color: rgb(200, 200, 200); border-right-color: rgb(200, 200, 200); border-bottom-color: rgb(200, 200, 200); padding-left: 1ex; margin-left: 0.8ex; color: rgb(102, 102, 102);"> <div class="PlainText">* "\s" (and maybe also "\t" and "\r"?) apparently needs to be used at<br> the very start of a string/localestring value (see (2)). But does it<br> also need to be used e.g. at the very end of such a value? (From common<br> practice, it appears that it at least doesn't need to be used for a<br> space somewhere in the middle of such a value.)</div> <div class="PlainText"><br> <div class="PlainText"><span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; background-color: rgb(255, 255, 255); display: inline !important">* What about "\t" and "\r"?</span><br style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; background-color: rgb(255, 255, 255)"> </div> </div> </blockquote> <div class="PlainText"> <div class="PlainText"><br> </div> <div class="PlainText">"\s" is definitely needed, and I would argue "\t", too, if spaces or tabs are wanted in a value before the first non-"space" character. On the other hand, values end at the end of the line, so a strict reading of the specification does not suggest that spaces and tabs need to be escaped there, but an author who wants those at the end would be wise to use the escapes, as implementations may vary. But for their part, implementations <i>should</i> include trailing space and tab characters in values. Spaces and tabs appearing other than at the beginning and end of a value do not need to be escaped, and for legibility they should not be. Any implementation that interprets literal spaces or tabs in the interior of a string or localestring value as anything other than themselves is definitely erroneous, and to my knowledge, there are no such implementations of any significance to be concerned about.</div> <div class="PlainText"><br> </div> <div class="PlainText">As for "\r". <span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; background-color: rgb(255, 255, 255); display: inline !important">The spec seems clear that for the purposes of .desktop files, literal carriage-return characters are not line terminators in their own right, and they do not combine with linefeed characters to serve as line terminators. They have no special significance, unless -- and this is ambiguous -- as characters that can be part of the "space" around equals signs separating keys from their values.</span><span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif;"> Authors would be wise to use the escape sequence instead of a literal carriage-return character </span><i style="color: inherit; font-size: inherit; font-variant-ligatures: inherit; font-variant-caps: inherit; font-weight: inherit;">everywhere</i><span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif;"> that they want to represent a carriage return in a value, and especially at the beginning and end. Doing so</span><span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif;"> </span><span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif;">will </span><span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif;">avoid the potential for misinterpretation by implementations that do not fully conform, and will avoid a variety of accompanying display quirks for people viewing or editing the file with a text editor. I would suggest that implementations include literal carriage-returns in the "space" that may appear around "=" signs. Anywhere else in a value, they should be treated as ordinary characters (this is the same treatment as I interpret is specified for literal spaces and tabs).<br> </span></div> <br> </div> <div class="PlainText">Overall: .desktop files should be interpreted as <i>binary</i> files with a human-readable-ish, text-like format. They are not text files, and should not be interpreted as such, even on systems where their character encoding and line-termination semantics happen to coincide with the local convention for text files.</div> <div class="PlainText"><br> </div> <div class="PlainText">--</div> <div class="PlainText"><br> </div> <div class="PlainText">John</div> <div class="PlainText"><br> </div> </span></font></div> <br> <hr> <font face="Arial" color="Gray" size="2"><br> Email Disclaimer: www.stjude.org/emaildisclaimer<br> Consultation Disclaimer: www.stjude.org/consultationdisclaimer<br> </font> </body> </html>