Bookworm's /etc/mailcap seems to break s-nail

[Jesper Dybdal]

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

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 =
s-nail: $MAILCAPS: /etc/mailcap: text/plain: ignored unknown
string/command: then exec emacsclient --alternate-editor =
s-nail: $MAILCAPS: /etc/mailcap: text/x-makefile: ignored unknown
string/command: then exec emacsclient --alternate-editor =
s-nail: $MAILCAPS: /etc/mailcap: text/x-c++hdr: ignored unknown
string/command: then exec emacsclient --alternate-editor =
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

[Greg Wooledge]

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

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 =

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.

[Jesper Dybdal]

Post by Greg Wooledge

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

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 =

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!

[Max Nikulin]

Post by Greg Wooledge

s-nail: $MAILCAPS: /etc/mailcap: text/english: ignored unknown
string/command: then exec emacsclient --alternate-editor =

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.

[Max Nikulin]

Post by Max Nikulin
1. It does not perform an unquote pass that should retain only a half of
backslashes from Exec field of .desktop file.
(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"

[Jesper Dybdal]

Post by Max Nikulin

s-nail: $MAILCAPS: /etc/mailcap: text/english: ignored unknown
string/command: then exec emacsclient --alternate-editor =

...
...

Post by Max Nikulin
2. It does not skip x-scheme-handler/* entries. Are there applications
that may use such entries?
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

[Max Nikulin]

Post by Jesper Dybdal

Post by Max Nikulin
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.

Post by Jesper Dybdal

Post by Max Nikulin
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.

Post by Jesper Dybdal
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.

[Max Nikulin]

Post by Max Nikulin
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.

[Jonathan Dowland]

Post by Max Nikulin

Post by Max Nikulin
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.

[Max Nikulin]

Post by Jonathan Dowland

Post by Max Nikulin
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

Post by Jonathan Dowland
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

Post by Jonathan Dowland
-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

Post by Jonathan Dowland
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.

Post by Jonathan Dowland
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.

[Jonathan Dowland]

Post by Max Nikulin
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!)
…

Thank you for sharing these upstream bugs. They make for fascinating
(if occasionally horrifying) reading.

Post by Max Nikulin
Finally, I think that s-nail should ignore malformed mailcap entries.

I agree.

Post by Max Nikulin

Post by Jonathan Dowland
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.

[Jesper Dybdal]

Post by Max Nikulin
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.)

[David Wright]

Post by Jesper Dybdal
   mailcap/oldstable,now 3.69 all [installed,automatic]
   s-nail/oldstable,now 14.9.22-1 amd64 [installed]
   mailcap/stable,now 3.70+nmu1 all [installed,automatic]
   j-nail/stable,now 14.9.24-2 amd64 [installed]

↑

Post by Jesper Dybdal
Has anyone else seen this?

No.

Cheers,
David.

[Max Nikulin]

Post by Jesper Dybdal
   mailcap/stable,now 3.70+nmu1 all [installed,automatic]
   j-nail/stable,now 14.9.24-2 amd64 [installed]

↑

Post by Jesper Dybdal
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.