Re: Bookworm's /etc/mailcap seems to break s-nail
On Fri May 17, 2024 at 11:56 AM BST, Max Nikulin wrote: > You may file an issue to the emacs bug tracker. I didn't realise this was coming straight from upstream. If it were a Debian-local issue, I'd file something, but I will respectfully decline to engage with Emacs upstream. (Interesting to see another user of debbugs out there Today, besides Debian!) > However at least one developer was against wrappers: … Thank you for sharing these upstream bugs. They make for fascinating (if occasionally horrifying) reading. > Finally, I think that s-nail should ignore malformed mailcap entries. I agree. > On 16/05/2024 14:48, Jonathan Dowland wrote: > > Please do not CC me for listmail. > > You still decided to add my address to CC despite I joined to the > thread, not started it. I expect it is enough to guess that I am able to > follow the discussion even not being subscribed. So I did: Apologies! It seems my new favourite MUA (aerc) does not handle list replies by default as I would like it to/as I was used to with mutt. I will be more careful. -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Re: Bookworm's /etc/mailcap seems to break s-nail
On 2024-05-15 17:51, Max Nikulin wrote: I have filed https://bugs.debian.org/1071036 update-mime does not escape semicolon in .desktop Exec entries Thanks! I should have done that, but I've postponed it because I felt I didn't know enough about the context. (I just run Emacs on a Debian server box, shoving emacs frames on an X server running under Windows.) -- Jesper Dybdal https://www.dybdal.dk
Re: Bookworm's /etc/mailcap seems to break s-nail
On 16/05/2024 14:48, Jonathan Dowland wrote: On Wed May 15, 2024 at 4:51 PM BST, Max Nikulin wrote: https://bugs.debian.org/1071036 update-mime does not escape semicolon in .desktop Exec entries Re-reading your bug report I'm struck by how hard to reason about (and test) the emacs .desktop Exec= line is. Personally I'd break that out to a separate wrapper script, which wouldn't fix the root issue you've identified, but wouldn't trigger it. You may file an issue to the emacs bug tracker. I agree that more simple Exec entries in .desktop files will be easier to maintain. However at least one developer was against wrappers: https://debbugs.gnu.org/57752#8 Lars Ingebrigtsen, Tue, 13 Sep 2022 14:19:47 +0200 I'd prefer to have a .desktop file that works without any helper scripts. Later CVE-2023-27985 and CVE-2023-27986 were assigned for quoting in emacsclient .desktop files and there was an intermediate step: https://debbugs.gnu.org/60204 Actually a feature that allows to simplify .desktop files was added to the development branch despite strong opposition: https://debbugs.gnu.org/65902 -Exec=sh -c "u=\\$(echo \\"\\$1\\" | sed 's/[\\"]/&/g'); exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" --eval \\"(message-mailto \\"\\$u\\")\\"" sh %u +Exec=emacsclient --alternate-editor= --eval "(message-mailto (pop server-eval-args-left))" %u From my point of view, the following stance is spectacular: https://debbugs.gnu.org/65902#79 Eli Zaretskii, Thu, 14 Sep 2023 16:36:06 +0300 Emacs developers make mistakes even in the simple regexps we have in our code. That doesn't mean we should abandon regexps. The solution for sending Lisp forms to the server exists, and the quoting, although tricky in some cases, is not rocket science to get right. emacsclient.desktop still has a complex shell command. By the way, I have not noticed handling of %f substitutions in Emacs code for handling .desktop files, not to mention \n, \t, \s https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/dired-aux.el#n1364 shell-command-guess-xdg function Finally, I think that s-nail should ignore malformed mailcap entries. On 16/05/2024 14:48, Jonathan Dowland wrote: Please do not CC me for listmail. You still decided to add my address to CC despite I joined to the thread, not started it. I expect it is enough to guess that I am able to follow the discussion even not being subscribed.
Re: Bookworm's /etc/mailcap seems to break s-nail
On Wed May 15, 2024 at 4:51 PM BST, Max Nikulin wrote: > On 07/05/2024 23:24, Max Nikulin wrote: > >> On 2024-05-06 17:04, Max Nikulin wrote: > >>> So doubled backslashes (as in .desktop files) are correct. > >>> > >>> What is wrong is lack of backslashes added before ";" and it is a bug. > > I have filed > https://bugs.debian.org/1071036 > update-mime does not escape semicolon in .desktop Exec entries Thanks for persevering with this! Re-reading your bug report I'm struck by how hard to reason about (and test) the emacs .desktop Exec= line is. Personally I'd break that out to a separate wrapper script, which wouldn't fix the root issue you've identified, but wouldn't trigger it. -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Re: Bookworm's /etc/mailcap seems to break s-nail
On 07/05/2024 23:24, Max Nikulin wrote: On 2024-05-06 17:04, Max Nikulin wrote: So doubled backslashes (as in .desktop files) are correct. What is wrong is lack of backslashes added before ";" and it is a bug. I have filed https://bugs.debian.org/1071036 update-mime does not escape semicolon in .desktop Exec entries This particular bug almost certainly may be fixed by adding an extra line of perl code. However 2 layer of quoting in .desktop files: special rules for Exec and general for any strings require more work to get entries properly escaped for mailcap in general case. In the meanwhile I have realized that BASH implementation of parsing Exec entries in xdg-open fallback function search_desktop_file is really ugly: https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-open.in?ref_type=heads#L312 I am unsure if it is possible to implement double quotes rule https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s07.html Since xdg-open usually delegates handling of URIs to the desktop environment, this code is active only for those who avoid any DE.
Re: Bookworm's /etc/mailcap seems to break s-nail
On 07/05/2024 18:40, Jesper Dybdal wrote: On 2024-05-06 16:24, Max Nikulin wrote: 2. It does not skip x-scheme-handler/* entries. Are there applications that may use such entries? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291015 mime-support: run‐mailcap to understand URL notation and start sensible-browser if required. A kind of proposal to support x-scheme-handler entries. On 2024-05-06 17:04, Max Nikulin wrote: So doubled backslashes (as in .desktop files) are correct. What is wrong is lack of backslashes added before ";" and it is a bug. I have now removed the "x-scheme-handler/mailto" entry I do not think they really hurt, however they are most complex entries, so chance that some parser would be confused is higher. and added backslashes in all the emacsclient entries in mailcap, and the error messages are gone. If these edits are outside of user section then entries may be regenerated to original form during installing of some package. Please, consider filing a bug report.
Re: Bookworm's /etc/mailcap seems to break s-nail
On 2024-05-06 16:24, Max Nikulin wrote: On 06/05/2024 20:27, Greg Wooledge wrote: On Mon, May 06, 2024 at 02:53:10PM +0200, Jesper Dybdal wrote: s-nail: $MAILCAPS: /etc/mailcap: text/english: ignored unknown string/command: then exec emacsclient --alternate-editor = --display=\\"\\$DISPLAY\\" \\"\\$@\\" ... It seems there are a couple of bugs in update-mime: ... 2. It does not skip x-scheme-handler/* entries. Are there applications that may use such entries? On 2024-05-06 17:04, Max Nikulin wrote: So doubled backslashes (as in .desktop files) are correct. What is wrong is lack of backslashes added before ";" and it is a bug. I have now removed the "x-scheme-handler/mailto" entry and added backslashes in all the emacsclient entries in mailcap, and the error messages are gone. Thanks a lot to Max and everybody else who responsed. Jesper -- Jesper Dybdal https://www.dybdal.dk
Re: Bookworm's /etc/mailcap seems to break s-nail
On 06/05/2024 21:24, Max Nikulin wrote: It seems there are a couple of bugs in update-mime: 1. It does not perform an unquote pass that should retain only a half of backslashes from Exec field of .desktop file. I was wrong here. mailcap(5): (In fact, the backslash can be used to quote any character, including itself.) So doubled backslashes (as in .desktop files) are correct. What is wrong is lack of backslashes added before ";" and it is a bug. grep Exec /usr/share/applications/emacsclient.desktop Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient --alternate-editor= --create-frame; fi" sh %F should be converted to /etc/mailcap entry application/x-shellscript; sh -c "if [ -n \\"\\$*\\" ]\; then exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"\; else exec emacsclient --alternate-editor= --create-frame\; fi" sh %s; test=test -n "$DISPLAY"
Re: Bookworm's /etc/mailcap seems to break s-nail
On 06/05/2024 21:41, David Wright wrote: On Mon 06 May 2024 at 14:53:10 (+0200), Jesper Dybdal wrote: * In Bookworm: mailcap/stable,now 3.70+nmu1 all [installed,automatic] j-nail/stable,now 14.9.24-2 amd64 [installed] ↑ Has anyone else seen this? Do you have emacs installed? Rare .desktop files have complex shell commands inside. emacsclient treats --display option in a quite specific way, so it needs --display="$DISPLAY". Moreover, there is no way to pass to emacs "server" arguments like URIs using something similar to argv. That is why it is necessary to escape arguments used in lisp expressions emacsclient --eval "(FUNCTION \"ARGUMENT\")" Emacs developers are against helper scrips as dedicated files, so there are inline script in Exec filed of .desktop files.
Re: Bookworm's /etc/mailcap seems to break s-nail
On Mon 06 May 2024 at 14:53:10 (+0200), Jesper Dybdal wrote: > The package versions involved are: > * in Bullseye: > mailcap/oldstable,now 3.69 all [installed,automatic] > s-nail/oldstable,now 14.9.22-1 amd64 [installed] > * In Bookworm: > mailcap/stable,now 3.70+nmu1 all [installed,automatic] > j-nail/stable,now 14.9.24-2 amd64 [installed] ↑ > Has anyone else seen this? No. Cheers, David.
Re: Bookworm's /etc/mailcap seems to break s-nail
On 06/05/2024 20:27, Greg Wooledge wrote: On Mon, May 06, 2024 at 02:53:10PM +0200, Jesper Dybdal wrote: s-nail: $MAILCAPS: /etc/mailcap: text/english: ignored unknown string/command: then exec emacsclient --alternate-editor = --display=\\"\\$DISPLAY\\" \\"\\$@\\" The question (one of the questions) is what's putting them there, and I would guess one of the emacs packages is doing it. update-mime(8) § DESKTOP ENTRIES In addition to the abovementioned mechanism update-mime also parses desktop entries in /usr/share/applications/ to generate mailcap entries. These entries are given a lower priority than those in /usr/lib/mime/packages. It seems there are a couple of bugs in update-mime: 1. It does not perform an unquote pass that should retain only a half of backslashes from Exec field of .desktop file. 2. It does not skip x-scheme-handler/* entries. Are there applications that may use such entries? Perhaps there is a bug in s-nail as well.
Re: Bookworm's /etc/mailcap seems to break s-nail
On 2024-05-06 15:27, Greg Wooledge wrote: On Mon, May 06, 2024 at 02:53:10PM +0200, Jesper Dybdal wrote: I use s-nail as my mailx command (selected using the Debian "alternatives" mechanism). Since I upgraded from Bullseye to Bookworm, s-nail now shows a bunch of error messages in connection with viewing messages. Here is a sample: s-nail: $MAILCAPS: /etc/mailcap: x-scheme-handler/mailto: ignored unknown string/command: u = \\${u//\\"/\\"} s-nail: $MAILCAPS: /etc/mailcap: text/english: ignored unknown string/command: then exec emacsclient --alternate-editor = --display=\\"\\$DISPLAY\\" \\"\\$@\\" I don't have lines like this in mine. Then again, I don't have emacs installed. The question (one of the questions) is what's putting them there, and I would guess one of the emacs packages is doing it. I have no particular wish to learn about /etc/mailcap. The only way I've found to avoid this is to remove the /etc/mailcap file entirely. I would think deleting any lines containing "emacs" would be slightly less invasive. Obviously, make a backup copy of the file first. That might be an excellent idea. I've removed all lines with "emacsclient" (there were also some with "emacs", but not "emacsclient"), and the error messages have disappeared. Since I only use s-nail rarely. it may be a while before I know whether that removal also has negative consequences. Thanks a lot, Greg! -- Jesper Dybdal https://www.dybdal.dk
Re: Bookworm's /etc/mailcap seems to break s-nail
On Mon, May 06, 2024 at 02:53:10PM +0200, Jesper Dybdal wrote: > I use s-nail as my mailx command (selected using the Debian "alternatives" > mechanism). > > Since I upgraded from Bullseye to Bookworm, s-nail now shows a bunch of > error messages in connection with viewing messages. Here is a sample: > > s-nail: $MAILCAPS: /etc/mailcap: x-scheme-handler/mailto: ignored > > unknown string/command: u = \\${u//\\"/\\"} > > s-nail: $MAILCAPS: /etc/mailcap: text/english: ignored unknown > > string/command: then exec emacsclient --alternate-editor = > > --display=\\"\\$DISPLAY\\" \\"\\$@\\" I don't have lines like this in mine. Then again, I don't have emacs installed. The question (one of the questions) is what's putting them there, and I would guess one of the emacs packages is doing it. > I have no particular wish to learn about /etc/mailcap. The only way I've > found to avoid this is to remove the /etc/mailcap file entirely. I would think deleting any lines containing "emacs" would be slightly less invasive. Obviously, make a backup copy of the file first.
Bookworm's /etc/mailcap seems to break s-nail
I use s-nail as my mailx command (selected using the Debian "alternatives" mechanism). Since I upgraded from Bullseye to Bookworm, s-nail now shows a bunch of error messages in connection with viewing messages. Here is a sample: s-nail: $MAILCAPS: /etc/mailcap: x-scheme-handler/mailto: ignored unknown string/command: u = \\${u//\\"/\\"} s-nail: $MAILCAPS: /etc/mailcap: text/english: ignored unknown string/command: then exec emacsclient --alternate-editor = --display=\\"\\$DISPLAY\\" \\"\\$@\\" s-nail: $MAILCAPS: /etc/mailcap: text/plain: ignored unknown string/command: then exec emacsclient --alternate-editor = --display=\\"\\$DISPLAY\\" \\"\\$@\\" s-nail: $MAILCAPS: /etc/mailcap: text/x-makefile: ignored unknown string/command: then exec emacsclient --alternate-editor = --display=\\"\\$DISPLAY\\" \\"\\$@\\" s-nail: $MAILCAPS: /etc/mailcap: text/x-c++hdr: ignored unknown string/command: then exec emacsclient --alternate-editor = --display=\\"\\$DISPLAY\\" \\"\\$@\\" s-nail: $MAILCAPS: /etc/mailcap: text/x-c++src: ignored unknown string/command: then exec emacsclient --alternate-editor I have no particular wish to learn about /etc/mailcap. The only way I've found to avoid this is to remove the /etc/mailcap file entirely. The package versions involved are: * in Bullseye: mailcap/oldstable,now 3.69 all [installed,automatic] s-nail/oldstable,now 14.9.22-1 amd64 [installed] * In Bookworm: mailcap/stable,now 3.70+nmu1 all [installed,automatic] j-nail/stable,now 14.9.24-2 amd64 [installed] Has anyone else seen this? Thanks, Jesper -- Jesper Dybdal https://www.dybdal.dk