On Tuesday, June 25, 2024 12:42 PM, meator <[email protected]> > On 6/25/24 18:13, Bollinger, John wrote: > > > I have also messaged this mailing list about this > > > (See "A few questions about escaping in desktop files" sent in 22. > > > August 2022). In this thread, I was assured that the implementation can > > > either choose to do word splitting and unquoting itself or it can pass > > > the job to a shell. > > > > I do not find that surprising, but the spec really ought to be clear > > about it. > > [...] all of this is still > speculation I believe. But I found the arguments made on that thread > reasonable. > > I have reread the thread (it has been two years since I've discussed > this). Here's a link if you're curious: > https://lists.freedesktop.org/archives/xdg/2022-August/014620.html > > The argument made is that there already exist two major implementations > handling the Exec key either way. This means that both the shell > approach and the manual approach "are correct", because if they aren't, > it would make a major implementation not compliant, which would make the > specification less reliable and it would anger other implementers too.
I think where you say "less reliable", it would be more apt to say "unacceptable to the overall community". And even if it were not the original intent that both approaches should be acceptable, if that is the de facto interpretation then that's the position from which any changes or interpretations must be made. Though in truth, I have trouble reading the spec as intending otherwise. > > --- > > > > [spec draft] > > > --- I +1 your efforts. It would be nice to see clarification in the specification. You also impose stricter rules on quoting which would make passing the arguments to the shell feasible. The way I see it, no, I don't. On one hand, none of the specifics laid out in that draft wording are rules in their own right. They are all _consequences_ of the general rule that an implementation should have its choice of running the command via a shell or parsing the command line and exec()ing the result directly. On the other hand, that general rule seems to convey the prevailing interpretation of the spec, so even though some of those specifics are not spelled out in the current spec, they are nevertheless implied by it anyway. > This would remove behavior discrepancies between the shell approach and the manual approach. Yes, to the extent that there are any desktop files that actually trigger such differences now. But I'm inclined to think that those tend to get ironed out when a project gets bug reports about its desktop files not working with one desktop environment or another. Which is another reason to take what I describe as a more explicit expression of the de facto requirements of the current spec, rather than as conveying any new or fundamentally different requirements. > One disadvantage I see is that the entire shell quoting mechanism has to > be specified here. No, it doesn't. In fact, it _isn't_ (believe it or not) in the draft wording I presented (see also below). > Shell is not directly related to desktop files. > Implementations choosing to handle the Exec key manually will not even > involve a shell altogether. This imposes a pretty hard artificial > dependency on the /bin/sh quoting mechanism. Shell _is_ directly related to desktop files if it is a rule, whether explicit or not, that the value of the Exec key needs to be interpretable in a certain way by the shell. And although the spec doesn't say so explicitly, I do, again, think that that is a de facto rule. Specifically, as I expressed it in the draft text: "commands must be quoted and escaped such that their interpretation according to the shell's rules does not differ from their interpretation according to the more limited delimiting, quoting, and escaping rules presented in this specification." However, having expressed that rule in the spec, it would be possible to provide less precise guidance on how to satisfy that, closer in style to the current quoting rules. One needs to understand, however, that the current rules are inadequate for their apparent intended purpose. If we are interpreting that purpose correctly then that is a deeper flaw in the spec than just not covering square brackets, yet one that I don't think would be a major issue to fix, even if the change could be interpreted as backwards incompatible. > the main issue I've outlined in the > originating e-mail of this thread is globbing. Yes, I know and understand. > Implementations using the > shell for handling of Exec will treat the following line: > > > Exec=/usr/bin/xte[r]m > > as /usr/bin/xterm (if xterm is installed on the system in the expected > location). This is true unless these implementations employ special code > for [, which is not likely, because it is not specified. Yes. > Implementations doing word splitting and unquoting manually will see > /usr/bin/xte[r]m, Yes. > which is arguably the correct behavior. Maybe. Inasmuch as I perceive a de facto rule that Exec values must be quoted appropriately to ensure that there is no such difference in interpretation, I would argue that that Exec value is non-conforming. If it appeared in a real desktop file, I would find it eminently reasonable to file a bug report about that with the project providing that file. > If the desktop file should choose to invoke [ (as in /usr/bin/[), I > believe that no special treatment is necessary. Agreed. And the general rule I keep coming back to is consistent with that. > I would also like to point out that "real" desktop files used in > production will never contain these special edge-cases were discussing. Provisionally agreed. Certainly I don't expect ever to see anything analogous to Exec=/usr/bin/xte[r]m. But I'm not so quick to accept that I shouldn't expect ever to see *any* real-world example that satisfies the explicit quoting rules in the current version of the spec, but nevertheless is handled differently by different desktop environments. Such an example probably wouldn't involve square brackets, but I am in no way so sure about shell reserved words, for example. > But still, the specification should be clear. Yes. I may just submit a PR with some variation of my draft revision, and see what happens. > Because of this thread and because of other concerns, I chose to switch > the Exec handling mechanism of j4-dmenu-desktop (a desktop file runner > program I maintain) from the shell approach to the manual one. Although that puts more work on the desktop file launcher, I do think it's the preferable approach. I never like to get a shell involved unless it's really needed. Best, John ________________________________ Email Disclaimer: www.stjude.org/emaildisclaimer Consultation Disclaimer: www.stjude.org/consultationdisclaimer
