bug#74467: 31.0.50; org-protocol emacsclient.desktop change is not fully functional

["Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Ihor Radchenko <yantar92@posteo.net> writes:

> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>
>>> -Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient
>>> --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else
>>> exec emacsclient --alternate-editor= --create-frame; fi" sh %F
>>> +Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient
>>> --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else
>>> exec emacsclient --alternate-editor= --create-frame; fi" sh %U
>>
>> Do we need the shell code here? if DISPLAY is defined emacsclient could
>> shurely forward it to Emacs.
>
> I think that reasons why sh is there have nothing to do with the issue
> at hand.
>
>> Shellcode is part of the issue.
>
> How so?
> The first message in this thread described exactly why the old version
> stopped working:
>
>     On 2023-10-03 there was a change introduced in xdg-utils
>     https://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=b9d3ecf8180c57dbb5ca47253898ba0553e81c60
>     to more strictly follow xdg specification, and only pass URL-like
>     arguments to programs that explicitly requested this by using '%u' or
>     '%U' parameters.

Calling a shell and then the program is more complicated as the argument
supplied to Emacs first run through the shell and then Emacs making the
arguments subject to the shell parsing rules.

> After the above change, %F in our .desktop file prevents xdg-open from
> using it for opening URIs. Any URIs, not just org-protocol and co.
>
> So, %U should fix it, except that it will also signal to xdg-open that
> Emacs can handle file:// URI as well; so we need to make sure that
> file:// URIs can be opened just fine.

It does fix that but dropping the shell in this context helps to avoid any
later potential issues.