bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error

bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error

[Mekeor Melire]

In GNU+Linux, in Xorg, with xdg-utils installed, and with
emacsclient.desktop[1] from Emacs repository installed, configure the
mapping from mime-types to applications by creating a file
~/.config/mimeapps.list with contents:

    [Default Applications]
    text/plain=emacsclient.desktop

Create a plain-text file and open it with the XDG default application:

    echo hello > example.txt
    xdg-open example.txt

I expect Emacsclient to start and open the file. Instead, I get the
following error messages which point to quoting-related problems.

    $ xdg-open example.txt
    egrep: warning: egrep is obsolescent; using grep -E
    [: -c: line 1: unexpected EOF while looking for matching `"'
    [: -c: line 2: syntax error: unexpected end of file
    [: -c: line 1: unexpected EOF while looking for matching `"'
    [: -c: line 2: syntax error: unexpected end of file
    [: -c: line 1: unexpected EOF while looking for matching `"'
    [: -c: line 2: syntax error: unexpected end of file

Apparently, since the default application Emacsclient exits with
failure, xdg-open then proceeds by trying out other applications that
have an installed .desktop-file. Thus another program opens the file.

Does anyone else experience this problem?

It seems like it is a problem introduced with bug#49195 / commit
cbf220bc31c0a00c45b22c140eda7854d81d991b [2]. All versions of the Exec=
line of emacsclient.desktop result in the same erroneous behavior for me
since this commit. I.e. the last version that works is just:

    Exec=emacsclient -c %F

Please let me know if you can or cannot reproduce this, because it might
also possibly be a bug in my OS distribution, GNU Guix System.

By the way, I'm using the latest version of xdg-utils, 1.1.3, probably
released on 2018-05-10.



In GNU Emacs 30.0.50 (build 1, x86_64-unknown-linux-gnu, Motif Version
2.3.8, cairo version 1.16.0)
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Guix System

Configured using:
 'configure
 CONFIG_SHELL=/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash
 SHELL=/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash
 --prefix=/gnu/store/whmdrrv8db90a238jgjy24hd13diljfl-emacs-next-motif-30.0.50-1.9d27b95
 --enable-fast-install --build=x86_64-unknown-linux-gnu
 --with-x-toolkit=motif --with-modules --with-native-compilation=aot
 --disable-build-details'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM XPM MOTIF ZLIB



[1]  https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/emacsclient.desktop
[2]  https://git.savannah.gnu.org/cgit/emacs.git/commit/etc/emacsclient.desktop?id=cbf220bc31c0a00c45b22c140eda7854d81d991b

bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error

[Eli Zaretskii]

> From: Mekeor Melire <mekeor@posteo.de>
> Date: Sun, 10 Dec 2023 00:13:33 +0000
> 
> In GNU+Linux, in Xorg, with xdg-utils installed, and with
> emacsclient.desktop[1] from Emacs repository installed, configure the
> mapping from mime-types to applications by creating a file
> ~/.config/mimeapps.list with contents:
> 
>     [Default Applications]
>     text/plain=emacsclient.desktop
> 
> Create a plain-text file and open it with the XDG default application:
> 
>     echo hello > example.txt
>     xdg-open example.txt
> 
> I expect Emacsclient to start and open the file. Instead, I get the
> following error messages which point to quoting-related problems.
> 
>     $ xdg-open example.txt
>     egrep: warning: egrep is obsolescent; using grep -E
>     [: -c: line 1: unexpected EOF while looking for matching `"'
>     [: -c: line 2: syntax error: unexpected end of file
>     [: -c: line 1: unexpected EOF while looking for matching `"'
>     [: -c: line 2: syntax error: unexpected end of file
>     [: -c: line 1: unexpected EOF while looking for matching `"'
>     [: -c: line 2: syntax error: unexpected end of file
> 
> Apparently, since the default application Emacsclient exits with
> failure, xdg-open then proceeds by trying out other applications that
> have an installed .desktop-file. Thus another program opens the file.

Why does emacsclient exit with a failure in that case?  When I try
invoking emacsclient from the shell prompt, it exits with a zero exit
status, not with a failure.

> It seems like it is a problem introduced with bug#49195 / commit
> cbf220bc31c0a00c45b22c140eda7854d81d991b [2]. All versions of the Exec=
> line of emacsclient.desktop result in the same erroneous behavior for me
> since this commit. I.e. the last version that works is just:
> 
>     Exec=emacsclient -c %F

What is the command that is run with the current emacsclient.desktop
file?

bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error

[Mekeor Melire]

2023-12-10 08:17 eliz@gnu.org:

> Why does emacsclient exit with a failure in that case?  When I try
> invoking emacsclient from the shell prompt, it exits with a zero exit
> status, not with a failure.

Invoking emacsclient from shell prompt directly, works just fine for me
too. Supposedly, it's not emacsclient that exists with failure but the
sh command mentioned below.

> What is the command that is run with the current emacsclient.desktop
> file?

Unfortunately, I don't know which command xdg-open tries to execute
exactly. But the configuration (in Emacs' emacsclient.desktop) is this:

    Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient
    --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec
    emacsclient --alternate-editor= --create-frame; fi" sh %F

    https://git.sv.gnu.org/cgit/emacs.git/tree/etc/emacsclient.desktop?h=cf11fdfd8e460d966ba279f00633ab378038de68#n6

Note that the Exec key of .desktop files has very complicated quoting
rules:

    https://specifications.freedesktop.org/desktop-entry-spec/1.1/ar01s06.html

By the way, I found a recent bug report on the Github website of the
Telegram-Desktop repository that mentions the same problem that I'm
experiencing:

    https://github.com/telegramdesktop/tdesktop/issues/27100

Actually, I have the feeling that this is a bug in xdg-utils. I will
file a bug report there.

In the mean time, should we work-around this bug by just using this or
something similar?:

    Exec=emacsclient --alternate-editor= --create-frame %F

bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error

[Mekeor Melire]

2023-12-10 11:14 mekeor@posteo.de:

> 2023-12-10 08:17 eliz@gnu.org:
> Actually, I have the feeling that this is a bug in xdg-utils. I will
> file a bug report there.

Actually, there are already bug-reports on xdg-utils for this, also
mentioning emacsclient.desktop explicitely:

https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/236
https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/174

> In the mean time, should we work-around this bug by just using this or
> something similar?:
>
>     Exec=emacsclient --alternate-editor= --create-frame %F

Should we close this very bug or should we implement a work-around?

E.g we could stop using a complex, nested invokation of sh, and instead
just execute emacsclient with some arguments, without any need for
quoting, as I mentioned.

Altenatively, we could ship an executable.sh which invokes emacsclient
appropriately. [1] But the quoting of Exec= lines in .desktop-files is
just flawed right now.

[1] As suggested here: "The quicker fix will probably be having a script
     somewhere in the filesystem that handles that logic."
     https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/236#note_2169234

bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error

[Eli Zaretskii]

> From: Mekeor Melire <mekeor@posteo.de>
> Cc: 67736@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Sun, 10 Dec 2023 11:28:37 +0000
> 
> Actually, there are already bug-reports on xdg-utils for this, also
> mentioning emacsclient.desktop explicitely:
> 
> https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/236
> https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/174
> 
> > In the mean time, should we work-around this bug by just using this or
> > something similar?:
> >
> >     Exec=emacsclient --alternate-editor= --create-frame %F
> 
> Should we close this very bug or should we implement a work-around?

As I wrote earlier, I'd like to wait until we understand more about
the various aspects of this issue.

> E.g we could stop using a complex, nested invokation of sh, and instead
> just execute emacsclient with some arguments, without any need for
> quoting, as I mentioned.

I don't think this is TRT.  We have all that complexity for a reason.
Please look at Git history of that file to see how we arrived at what
we have now.

bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error

[Mekeor Melire]

2023-12-10 13:56 eliz@gnu.org:

> We have all that complexity for a reason. Please look at Git history
> of that file to see how we arrived at what we have now.

Let's take a look at the commit-history of the Exec= line of the
emacsclient.desktop file [1]. It was introduced in the following
commit with a very simple and comprehensible Exec= line.

    Commit:  1a845a672dc73c8e98e6cb9bb734616e168e60ba
    Date:    Sun Aug 9 15:57:51 2020 +0200
    Author:  Carlos Pita <carlosjosepita@gmail.com>
    Message: Add file, use emacsd as StartupWMClass.
    Code:    Exec=emacsclient -c %F

Then, there were discussions at bug#49195, bug#49505 and
emacs-devel-thread "GUI X-FreeDesktop integration" [2] which resulted
in the following commit which changed the Exec= line and made it much
more complex by invoking a shell:

    Commit:  cbf220bc31c0a00c45b22c140eda7854d81d991b
    Date:    Wed Jun 30 15:11:21 2021 +0200
    Author:  Peter Oliver <p.d.oliver@mavit.org.uk>
    Message:
        From .desktop files, reuse a frame or start a new Emacs as
        required. Automatically try to reuse an existing frame, open a
        new frame, or start a new Emacs daemon. Add actions for
        specific behaviours (bug#49195).
    Documentation:
        You may use the "Emacs (Client)" menu entry to connect to an
        Emacs server with emacsclient. The daemon starts if not
        already running.
    Code:
        Exec=sh -c 'if [ -n "$*" ]; then exec emacsclient
        --alternate-editor= --display="$DISPLAY" "$@"; else exec
        emacsclient --alternate-editor= --create-frame; fi'
        placeholder %F

The commit-message, the committed documentation and the
patch-submission-message (at bug#49195) explain that
emacsclient.desktop will now start a daemon when not already running.
This is achieved by passing --alternate-editor=.

But all of these resources fail to mention the reason for the shell
invocation. It can be reconstructed in a message [3] from Peter
Oliver, in a thread on emacs-devel:

    I believe that the default behaviour when opening a file from a
    desktop’s file manager should be to open it in an existing GUI
    frame if one exists, or a new GUI frame if one does not. Clicking
    Emacs in a desktop’s application launcher should open a new GUI
    frame.

    The trouble is that, if Emacs is running as a daemon with no
    frames, `emacsclient /path/to/foo` will create a new TTY frame
    rather than a GUI frame. Should this behaviour be changed so that
    a GUI frame is preferred if $DISPLAY is set? While we’re here,
    should we report an error if there is no display and no TTY?

I.e. the purpose of the shell invocation is to be able to use the
shell-conditional

    if [ -n "$*" ]

in order to check if no arguments (file-paths) have been passed to
emacsclient.desktop (i.e. e.g. if the user double-clicked a file in a
file-explorer for which emacsclient.desktop configured to be the default
application); or otherwise if there were no arguments passed (i.e. e.g.
if the user clicked on the emacsclient.desktop-icon in their
application-launcher).

In the first case ("Open one or more specified files in Emacsclient"),
--desktop=$DESKTOP is passed as additional command-line parameter;
whereas in the second case ("Open Emacsclient, but no file(s) in
particular"), --create-frame is passed additionally.

For me, personally, the emacsclient.desktop is unusable because of an
error at an earlier stage. Namely, something goes wrong when XDG invokes
the shell, due to the quoting/escaping syntax. The two last commits on
the Exec= line tried to fix this already but it still does not work for
me:

    Commit: 0a4b66f82752adeb808851a36eabd0554779b33c
    Author: Peter Oliver <p.d.oliver@mavit.org.uk>
    Date:   Wed Jul 7 22:04:01 2021 +0100
    Message:
        Valid quoting in .desktop files. Quote according to the rules
        in the Freedesktop.org Desktop Entry Specification.
    Code:
        Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient
        --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\";
        else exec emacsclient --alternate-editor= --create-frame; fi"
        placeholder %F

    Commit: d32091199ae5de590a83f1542a01d75fba000467
    Author: Ulrich Müller <ulm@gentoo.org>
    Date:   Mon Dec 19 16:51:20 2022 +0100
    Message:
        Use `sh` rather than `placeholder` as the command name of the
        shell wrapper. (Bug#60204)
    Code:
        Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient
        --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\";
        else exec emacsclient --alternate-editor= --create-frame; fi"
        sh %F

The reason for our struggle with the escaping-rules of the Exec-line
in .desktop-files are:

(1.) They are very complex. [5]

(2.) xdg-utils is buggy. [6] It does not implement its own
escaping-specification correctly. Other software projects do not run
into this bug because they do not have such uncommonly complex
Exec-lines in their .desktop-files. And it sounds like it'll take the
freedesktop.org-developers a long time to fix the bug, firstly because
it'll involve a rewrite of that part of xdg-utils in another programming
language (Python instead of Shell), and secondly because the project was
pretty dead for a long time until it only recently gained some momentum
in July 2023.

Note that I don't know if the .desktop-file works fine on MacOS. But I
doubt that it works for any GNU+Linux user because there haven't been
any releases of xdg-utils in recent years, AFAIK.

In this bug-report I do not want to raise the question which
command-line flags/parameters (--create-frame, --display,
--alternate-editor etc.) are passed to emacsclient by default. I'm
reporting that the .desktop-file does not work for me and probably for
none GNU+Linux-user at all. And because of the bug-, maintenance- and
project-related situation of xdg-utils, which indicates that a bug-fix
will take a long time, I'd like to propose to ditch the complex
shell-invocation (which necessarily involves the buggy escaping) and
instead use a simple and concise one-line, e.g.:

    Exec=emacsclient --alternate-editor= --create-frame %F

(Or maybe use the recently added --reuse-frame flag instead of
--create-frame.) Note that we would not loose the "Start an Emacs-Daemon
if not started" logic which was the justification for the commit which
introduced the shell-invocation (since we keep --alternate-editor=). We
would only loose the "create a frame if triggered without
file-arguments" logic which seems to be a rather personal taste anyway
because the respective message had not gotten any responses from others.
(See [3].)



[1]  You can easily do so yourself by calling
     `magit-log-trace-definition' when point is on the respective
     line.

[2]  Message-ID <20210514031825.zcgswqzuxrkktrgs@E15-2016.optimum.net>,
     https://yhetil.org/emacs-devel/20210514031825.zcgswqzuxrkktrgs@E15-2016.optimum.net/

[3]  Message-ID <573eb311-e0f6-2216-4298-458ae8ab827b@froglet.home.mavit.org.uk>,
     https://yhetil.org/emacs-devel/573eb311-e0f6-2216-4298-458ae8ab827b@froglet.home.mavit.org.uk/

[3]  The shell invocation looks like:

         sh -c COMMAND_STRING COMMAND_NAME ARGUMENTS

     where:

     - `sh' refers to a POSIX-compliant shell. (Often linked to bash,
     dash or zsh.) According to POSIX, the parameter `-c' enables
     passing and executing commands, COMMAND_STRING.

     - As COMMAND_NAME, which specifies the "name of the shell, which
     is used in warning and error messages"[4], we pass `sh', which I
     find okay but `shell-spawning-emacsclient' seems more useful.

     - As ARGUMENTS, we have `%F' which, according to the
     freedesktop.org-documentation, represents the names of the files
     to be opened [4]:

           A list of files. Use for apps that can open several local
           files at once. Each file is passed as a separate argument
           to the executable program.

[4]  POSIX-Specification:
     <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html>.
     BASH-documentation: (info "(bash) Invoking Bash") or
     <https://www.gnu.org/software/bash/manual/html_node/Invoking-Bash.html>.
     Elaborative response on stack-exchange-network:
     <https://superuser.com/a/1526230>.

[5]  https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s07.html

[6]  https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/236 and https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/174

bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error

[Peter Oliver]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

Mekeor Melire wrote:

>     $ xdg-open example.txt
>     egrep: warning: egrep is obsolescent; using grep -E
>     [: -c: line 1: unexpected EOF while looking for matching `"'
>     [: -c: line 2: syntax error: unexpected end of file
>     [: -c: line 1: unexpected EOF while looking for matching `"'
>     [: -c: line 2: syntax error: unexpected end of file
>     [: -c: line 1: unexpected EOF while looking for matching `"'
>     [: -c: line 2: syntax error: unexpected end of file
> 
> Does anyone else experience this problem?

I don’t experience it on Fedora, but I notice that the Fedora version of xdg-utils carries an awful lot of patches (https://src.fedoraproject.org/rpms/xdg-utils/tree/f38).

I agree that the quoting is too complex, and would be better eliminated.  A wrapper script could achieve the same functionality.


While I’m here, I’ll mention the other emacsclient.desktop issues that I’m aware of:

- Startup notification doesn’t work when opening files in an existing Emacs: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49504
- $DISPLAY is inappropriate for PGTK on Wayland, since it forces XWayland.
- emacsclient.desktop provides a superset of the functionality of emacs.desktop, but can’t replace it because there isn’t agreement that use of a daemon is suitable default behaviour.

-- 
Peter Oliver

bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error

[Ulrich Mueller]

>>>>> On Sun, 17 Dec 2023, Peter Oliver wrote:

> Mekeor Melire wrote:

>> $ xdg-open example.txt
>> egrep: warning: egrep is obsolescent; using grep -E
>> [: -c: line 1: unexpected EOF while looking for matching `"'
>> [: -c: line 2: syntax error: unexpected end of file
>> [: -c: line 1: unexpected EOF while looking for matching `"'
>> [: -c: line 2: syntax error: unexpected end of file
>> [: -c: line 1: unexpected EOF while looking for matching `"'
>> [: -c: line 2: syntax error: unexpected end of file
>> Does anyone else experience this problem?

> I don’t experience it on Fedora, but I notice that the Fedora version
> of xdg-utils carries an awful lot of patches
> (https://src.fedoraproject.org/rpms/xdg-utils/tree/f38).

I cannot reproduce the problem on Gentoo either. The Gentoo package uses
a snapshot of xdg-utils from 2021 because the 1.1.3 release is very old:
https://gitlab.freedesktop.org/xdg/xdg-utils/-/commits/1a58bc28f6844898532daf9ee1bf6da7764955a9/

(Also, xdg-utils-1.2.0 seems to be on its way; upstream has released a
1.2.0-beta1 version.)

> I agree that the quoting is too complex, and would be better
> eliminated.

I've double checked: The quoting in the desktop file is definitely
according to the specification. IMHO it isn't particularly complex in
emacsclient.desktop, at least compared to what we previously had in
emacsclient-mail.desktop.

> A wrapper script could achieve the same functionality.

All previous committers have avoided a wrapper script, because inlining
the shell command gets the work done.

Plus, wouldn't it be better to integrate the functionality of any
wrapper script in the emacsclient binary directly?


[Restoring some of the quoted context]

>>     Commit: d32091199ae5de590a83f1542a01d75fba000467
>>     Author: Ulrich Müller <ulm@gentoo.org>
>>     Date:   Mon Dec 19 16:51:20 2022 +0100
>>     Message:
>>         Use `sh` rather than `placeholder` as the command name of the
>>         shell wrapper. (Bug#60204)
>>     Code:
>>         Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient
>>         --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\";
>>         else exec emacsclient --alternate-editor= --create-frame; fi"
>>         sh %F

This commit didn't do anything significant for emacsclient.desktop, it
only changed the command name (which is shown e.g. in "ps" output) from
"placeholder" to "sh".

bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error

[Mekeor Melire]

[-- Attachment #1: Type: text/plain, Size: 6169 bytes --]

2023-12-17 16:35 ulm@gentoo.org:

> On Sun, 17 Dec 2023, Peter Oliver wrote:
>
> > I don’t experience it on Fedora, but I notice that the Fedora version
> > of xdg-utils carries an awful lot of patches
> > (https://src.fedoraproject.org/rpms/xdg-utils/tree/f38).
>
> I cannot reproduce the problem on Gentoo either. The Gentoo package uses
> a snapshot of xdg-utils from 2021 because the 1.1.3 release is very old:
> https://gitlab.freedesktop.org/xdg/xdg-utils/-/commits/1a58bc28f6844898532daf9ee1bf6da7764955a9/

Yes, many distros patch xdg-utils. On #emacs-IRC-channel I was even told
that file-explorers like GNOME's Nautilus and LXDE's pcmanfm tinker with
.desktop-files, e.g. they might ship their own emacsclient.desktop file.

So, when testing, do not use graphical file-managers. Instead, use the
xdg-open executable from xdg-utils package in a shell. Edit the file at
~/.config/mimeapps.list (or similar) yourself rather than letting some
GUI do it. And check the content of your emacsclient.desktop since it
might be altered by your distro. When sharing results, please also share
which version your xdg-utils package has, and which patches had been
applied on its source code before it was built.

Personally, I use xdg-utils 1.1.3, the latest stable release, installed
with Guix, which only includes some minor code-changes that make it find
executables on Guix System. [1] My emacsclient.desktop is from Emacs
master branch without changes.

Gentoo does not only build xdg-utils from an unreleased commit, but also
it applies some additional patches [2], one of which seems to alter the
handling of Exec-entries.

> (Also, xdg-utils-1.2.0 seems to be on its way; upstream has released a
> 1.2.0-beta1 version.)

Thanks for point this out. In reaction to your e-mail, I tried out the
1.2.0-beta1 version (using Guix and the package declaration that I
attached to this e-mail). Unfortunately, I'm still running in the same
error as before:

    [: -c: line 1: unexpected EOF while looking for matching `"'
    [: -c: line 2: syntax error: unexpected end of file

> > I agree that the quoting is too complex, and would be better
> > eliminated.
>
> I've double checked: The quoting in the desktop file is definitely
> according to the specification. IMHO it isn't particularly complex in
> emacsclient.desktop, at least compared to what we previously had in
> emacsclient-mail.desktop.

The problem is that xdg-utils does not adhere to its own specification.
It seems like some distros patched it to be better at that though.

I think a prior version of emacsclient-mail.desktop is bad reference for
comparison. Compared to other .desktop-files in the FOSS-world,
emacsclient.desktop has a very complicated, maybe the most complicated
Exec-entry. I can't prove this by representative statistics but only
refer to my own experience, and quote the reaction of the person, who by
far made the most commits on xdg-utils recently, when seeing the
emacsclient.desktop-files Exec-entry: "That is … one hell of an exec
line." [3]

> > A wrapper script could achieve the same functionality.
>
> All previous committers have avoided a wrapper script, because inlining
> the shell command gets the work done.

Which work does it get done though? The work is the "pass --create-frame
when there are no file-arguments" logic. And as far as I know, there
never was consensus for it.

> Plus, wouldn't it be better to integrate the functionality of any
> wrapper script in the emacsclient binary directly?

If there was consensus on a functionality that needed to be handled in
either a wrapper-script or in the emacsclient-binary itself, then yes.
But I don't think there is such a consensus.


Honestly, I don't know how to handle this tricky situation:
freedesktop.org has specification for Exec entries in .desktop-files.
xdg-utils itself does implement this specification correctly. Fixing the
bug will probably take its developers a long time because they want to
rewrite it (in Python). Meanwhile, xdg-utils is less/not buggy for most
users because their distro patches it.

Still, I know I'm not the only one who runs into the reported error
which makes emacsclient.desktop unusable.

Personally, I suggest to use, as Exec entry in emacsclient.desktop, a
simple one-liner that does not involve a shell-invocation, because it
will work for everyone.

In the long run, we might consider to: (1.) Use a similarly simple
one-liner as Exec entry, but also pass something like --xdg. (2.)
Provide Emacs users a customizable Elisp variable that specifies the
behavior of Emacsclient when passed --xdg.

> >>     Commit: d32091199ae5de590a83f1542a01d75fba000467
> >>     Author: Ulrich Müller <ulm@gentoo.org>
> >>     Date:   Mon Dec 19 16:51:20 2022 +0100
> >>     Message:
> >>         Use `sh` rather than `placeholder` as the command name of the
> >>         shell wrapper. (Bug#60204)
> >>     Code:
> >>         Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient
> >>         --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\";
> >>         else exec emacsclient --alternate-editor= --create-frame; fi"
> >>         sh %F
>
> This commit didn't do anything significant for emacsclient.desktop,

You are right. Sorry for the wrong contextualization.


[1]  https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/freedesktop.scm?h=60c97924e9519361494aaf0686e28eb831a42315#n517

[2]  One patch is mentioned here [4] and can be found here [5]. Another
     patch is located here [6] but does not seem to be significant with
     regards to Exec-behavior.

[3]  https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/236#note_2169234

[4]  https://github.com/gentoo/gentoo/blob/b3c1b324d58c92ad8b19c67d4aed20ecc5e5f021/x11-misc/xdg-utils/xdg-utils-1.1.3_p20210805-r1.ebuild#L13

[5]  https://dev.gentoo.org/~sam/distfiles/x11-misc/xdg-utils/xdg-utils-1.1.3_p20200220-no-which.patch.xz

[6]  https://github.com/gentoo/gentoo/blob/b3c1b324d58c92ad8b19c67d4aed20ecc5e5f021/x11-misc/xdg-utils/files/xdg-utils-egrep.patch


[-- Attachment #2: xdg-utils.scm --]
[-- Type: text/plain, Size: 882 bytes --]

(define-module (channel packages xdg-utils)
  #:use-module ((gnu packages freedesktop) #:prefix gnu:)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (guix gexp)
  #:use-module (guix git-download)
  #:use-module (guix modules)
  #:use-module (guix packages))

(define-public xdg-utils
  (let
    ( (commit "f8bc7454112899413a60996b7b5d9aebfa4e6864")
      (revision "1"))
    (package
      (inherit gnu:xdg-utils)
      (version (git-version "1.2.0.1" revision commit))
      (source
        (origin
          (method git-fetch)
          (file-name (git-file-name (package-name gnu:xdg-utils) version))
          (uri
            (git-reference
              (url "https://gitlab.freedesktop.org/xdg/xdg-utils.git")
              (commit commit)))
          (sha256
            (base32
              "1gw489c8lwy008wwa00qgcgf0hg4vclqxg1k74n0qh9s7kgqq8pr")))))))

bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error

[Ulrich Mueller]

>>>>> On Mon, 18 Dec 2023, Mekeor Melire wrote:

> So, when testing, do not use graphical file-managers. Instead, use the
> xdg-open executable from xdg-utils package in a shell. Edit the file at
> ~/.config/mimeapps.list (or similar) yourself rather than letting some
> GUI do it. And check the content of your emacsclient.desktop since it
> might be altered by your distro.

> When sharing results, please also share which version your xdg-utils
> package has, and which patches had been applied on its source code
> before it was built.

Sure. My /usr/share/applications/emacsclient.desktop is identical to the
one from Emacs master (as of today). Also, it is what is used for plain
text files:

   $ xdg-mime query default text/plain
   emacsclient.desktop

I've now also tested with xdg-utils-1.2.0-beta1 and with 1.1.3, manually
installed from the tarball available at:
https://gitlab.freedesktop.org/xdg/xdg-utils/-/tags/v1.1.3

I cannot reproduce the problem with either of them:

   $ xdg-open --version
   xdg-open 1.1.3
   $ echo hello >foo.txt && xdg-open foo.txt
   Waiting for Emacs...

This correctly visits the file in my running Emacs.

However, I also see that xdg-open delegates handling of the file to
exo-open from XFCE (and similar for GNOME, KDE, etc.). So maybe xdg-open
sometimes doesn't parse the desktop file by itself? Which would explain
why I don't see the problem.

> [...]

> The problem is that xdg-utils does not adhere to its own specification.
> It seems like some distros patched it to be better at that though.

> I think a prior version of emacsclient-mail.desktop is bad reference for
> comparison. Compared to other .desktop-files in the FOSS-world,
> emacsclient.desktop has a very complicated, maybe the most complicated
> Exec-entry. I can't prove this by representative statistics but only
> refer to my own experience, and quote the reaction of the person, who by
> far made the most commits on xdg-utils recently, when seeing the
> emacsclient.desktop-files Exec-entry: "That is … one hell of an exec
> line." [3]

The line conforms to the spec, so xdg-open should be able to handle it.
Then again, the line is "one hell" only because (IMHO) their own
specification sucks and requires complicated quoting plus multiple
telnet-song-esque backslash-escaping.

(Also I'm a little shocked by the reaction of the upstream person. It's
their specification and their reference implementation, so why don't
they have unit tests for all intricacies of the Exec line?)

> Honestly, I don't know how to handle this tricky situation:
> freedesktop.org has specification for Exec entries in .desktop-files.
> xdg-utils itself does implement this specification correctly.

Is a "not" missing there? Otherwise I don't understand the sentence.

> Fixing the bug will probably take its developers a long time because
> they want to rewrite it (in Python). Meanwhile, xdg-utils is less/not
> buggy for most users because their distro patches it.

*sigh* Standards exist for a reason, namely that developers can program
against them, instead of second-guessing other implementations.

I think we have established that the bug is in xdg-utils, so that's
where it should be ultimately fixed. Not sure if it's worth having a
short-term workaround using a wrapper script.

bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error

[Mekeor Melire]

2023-12-18 11:17 ulm@gentoo.org:

> > Honestly, I don't know how to handle this tricky situation:
> > freedesktop.org has specification for Exec entries in .desktop-files.
> > xdg-utils itself does implement this specification correctly.
>
> Is a "not" missing there? Otherwise I don't understand the sentence.

You are right, a "not" was missing.

> Standards exist for a reason, namely that developers can program
> against them, instead of second-guessing other implementations.
>
> I think we have established that the bug is in xdg-utils, so that's
> where it should be ultimately fixed. Not sure if it's worth having a
> short-term workaround using a wrapper script.

You are right. Let's close this bug. It's an upstream-bug.

bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error

[Eli Zaretskii]

> From: Mekeor Melire <mekeor@posteo.de>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Sun, 10 Dec 2023 11:14:25 +0000
> 
> 2023-12-10 08:17 eliz@gnu.org:
> 
> > Why does emacsclient exit with a failure in that case?  When I try
> > invoking emacsclient from the shell prompt, it exits with a zero exit
> > status, not with a failure.
> 
> Invoking emacsclient from shell prompt directly, works just fine for me
> too. Supposedly, it's not emacsclient that exists with failure but the
> sh command mentioned below.

And if you invoke that command from the shell, it does exit with a
failure status?

>     https://github.com/telegramdesktop/tdesktop/issues/27100
> 
> Actually, I have the feeling that this is a bug in xdg-utils. I will
> file a bug report there.

Thanks, let's see how they respond.

> In the mean time, should we work-around this bug by just using this or
> something similar?:
> 
>     Exec=emacsclient --alternate-editor= --create-frame %F

I have no idea what problems this could cause, so I'd prefer not to
change anything until we understand more and hear from xdg-utils
developers.