* bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error @ 2023-12-10 0:13 Mekeor Melire 2023-12-10 6:17 ` Eli Zaretskii 0 siblings, 1 reply; 12+ messages in thread From: Mekeor Melire @ 2023-12-10 0:13 UTC (permalink / raw) To: 67736 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error 2023-12-10 0:13 bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error Mekeor Melire @ 2023-12-10 6:17 ` Eli Zaretskii 2023-12-10 11:14 ` Mekeor Melire 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2023-12-10 6:17 UTC (permalink / raw) To: Mekeor Melire; +Cc: 67736 > 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error 2023-12-10 6:17 ` Eli Zaretskii @ 2023-12-10 11:14 ` Mekeor Melire 2023-12-10 11:28 ` Mekeor Melire 2023-12-10 11:54 ` Eli Zaretskii 0 siblings, 2 replies; 12+ messages in thread From: Mekeor Melire @ 2023-12-10 11:14 UTC (permalink / raw) To: 67736; +Cc: Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error 2023-12-10 11:14 ` Mekeor Melire @ 2023-12-10 11:28 ` Mekeor Melire 2023-12-10 11:56 ` Eli Zaretskii 2023-12-10 11:54 ` Eli Zaretskii 1 sibling, 1 reply; 12+ messages in thread From: Mekeor Melire @ 2023-12-10 11:28 UTC (permalink / raw) To: Mekeor Melire; +Cc: 67736, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error 2023-12-10 11:28 ` Mekeor Melire @ 2023-12-10 11:56 ` Eli Zaretskii 2023-12-17 0:14 ` Mekeor Melire 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2023-12-10 11:56 UTC (permalink / raw) To: Mekeor Melire; +Cc: mekeor, 67736 > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error 2023-12-10 11:56 ` Eli Zaretskii @ 2023-12-17 0:14 ` Mekeor Melire 2023-12-17 14:24 ` Peter Oliver 0 siblings, 1 reply; 12+ messages in thread From: Mekeor Melire @ 2023-12-17 0:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 67736, carlosjosepita, p.d.oliver, ulm 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error 2023-12-17 0:14 ` Mekeor Melire @ 2023-12-17 14:24 ` Peter Oliver 2023-12-17 15:35 ` Ulrich Mueller 0 siblings, 1 reply; 12+ messages in thread From: Peter Oliver @ 2023-12-17 14:24 UTC (permalink / raw) To: Mekeor Melire; +Cc: 67736, Eli Zaretskii, carlosjosepita, ulm [-- 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error 2023-12-17 14:24 ` Peter Oliver @ 2023-12-17 15:35 ` Ulrich Mueller 2023-12-17 23:06 ` Mekeor Melire 0 siblings, 1 reply; 12+ messages in thread From: Ulrich Mueller @ 2023-12-17 15:35 UTC (permalink / raw) To: Peter Oliver; +Cc: Mekeor Melire, 67736, Eli Zaretskii, carlosjosepita >>>>> 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". ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error 2023-12-17 15:35 ` Ulrich Mueller @ 2023-12-17 23:06 ` Mekeor Melire 2023-12-18 10:17 ` Ulrich Mueller 0 siblings, 1 reply; 12+ messages in thread From: Mekeor Melire @ 2023-12-17 23:06 UTC (permalink / raw) To: 67736; +Cc: Eli Zaretskii, Peter Oliver, carlosjosepita, Ulrich Mueller [-- 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"))))))) ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error 2023-12-17 23:06 ` Mekeor Melire @ 2023-12-18 10:17 ` Ulrich Mueller 2023-12-18 12:14 ` Mekeor Melire 0 siblings, 1 reply; 12+ messages in thread From: Ulrich Mueller @ 2023-12-18 10:17 UTC (permalink / raw) To: Mekeor Melire; +Cc: 67736, Eli Zaretskii, Peter Oliver, carlosjosepita >>>>> 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error 2023-12-18 10:17 ` Ulrich Mueller @ 2023-12-18 12:14 ` Mekeor Melire 0 siblings, 0 replies; 12+ messages in thread From: Mekeor Melire @ 2023-12-18 12:14 UTC (permalink / raw) To: 67736-done; +Cc: Ulrich Mueller, Peter Oliver, carlosjosepita, Eli Zaretskii 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error 2023-12-10 11:14 ` Mekeor Melire 2023-12-10 11:28 ` Mekeor Melire @ 2023-12-10 11:54 ` Eli Zaretskii 1 sibling, 0 replies; 12+ messages in thread From: Eli Zaretskii @ 2023-12-10 11:54 UTC (permalink / raw) To: Mekeor Melire; +Cc: 67736 > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-12-18 12:14 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-12-10 0:13 bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error Mekeor Melire 2023-12-10 6:17 ` Eli Zaretskii 2023-12-10 11:14 ` Mekeor Melire 2023-12-10 11:28 ` Mekeor Melire 2023-12-10 11:56 ` Eli Zaretskii 2023-12-17 0:14 ` Mekeor Melire 2023-12-17 14:24 ` Peter Oliver 2023-12-17 15:35 ` Ulrich Mueller 2023-12-17 23:06 ` Mekeor Melire 2023-12-18 10:17 ` Ulrich Mueller 2023-12-18 12:14 ` Mekeor Melire 2023-12-10 11:54 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).