Re: Image handling in mutt
On Mon 11 Dec 2023 at 10:03:38 (-0500), Pocket wrote:
> On 12/11/23 09:52, David Wright wrote:
> > On Sun 10 Dec 2023 at 15:51:02 (-0500), Pocket wrote:
> > > > On Dec 10, 2023, at 3:05 PM, David Wright wrote:
> > > > On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote:
> > > > > > On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote:
> > > > > > On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:
> > > > > > > I'm on Debian bookworm, using neomutt for email. Where there is an image to
> > > > > > > view, viewing it in neomutt calls up one of the ImageMagick programs. I've set
> > > > > > > the mailcap_path variable in my neomutt config to point to ~/.mailcap,
> > > > Similarly, I point it to ~/.config/mutt/mailcap-mutt, which is
> > > > a specially crafted subset of /etc/mailcap with a few additions
> > > > (like converting webp to a jpeg rather than opening in gimp,
> > > > and playing midi files the way I want).
> > > >
> > > > > > > and
> > > > > > > set an entry in there for image/jpg to point to /usr/bin/feh. I've even set
> > > > > > ↑↑↑ try jpeg
> > > > > >
> > > > > > > the "display" alternative to feh with update-alternatives. Still, mutt is
> > > > > > > calling an imagemagick program to display jpgs.
> > > > > > >
> > > > > > > First, if alternatives doesn't point to the imagemagick program, and the
> > > > > > > mailcap file doesn't point to it, and there's nothing in the neomutt config
> > > > > > > pointing to the imagemagick program, then where the heck is it getting that
> > > > > > > as the program to use to display images?
> > > > An email would contain headers with the attachment.
> > > >
> > > > ↓
> > > > Content-Type: image/jpeg
> > > > Content-Disposition: attachment; filename="don.jpg"
> > > > Content-Transfer-Encoding: base64
> > > >
> > > > By default, mutt searches six directories for a mailcap file. When
> > > > found, the line in the mailcap starting with image/jpeg selects the
> > > > program to run.
> > > >
> > > > If you see an extension in a mailcap field like nametemplate=%s.jpg
> > > > that's to show that a filename matching that pattern should be given
> > > > to a copy of the attachment to satisfy the program that's going to
> > > > read it. But it's the attachment /content type/ that selects the
> > > > program, not the extension¹.
> > > >
> > > > > > > Second, how do I fix this so that mutt uses feh to display images?
> > > > > I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and
> > > > > the files I was looking at had a "jpg" extension.
> > > > >
> > > > > But thanks for the tip.
> > > > A couple of programs in my /etc/mailcap (gpicview and gm) have
> > > > image/jpg lines, duplicating the image/jpeg entries, perhaps
> > > > as a "catch-all" for malformed emails containing image/jpg.
> > > > I don't know whether image/jpg is an official legacy type/iana-token.
> > > >
> > > > ¹ Re the argument raging in this thread about "extension", the
> > > > term is clearly appropriate, as a glance at /etc/mime.types
> > > > demonstrates. The literature is full of the term.
> > > >
> > > > I wouldn't want to use "suffix" myself, as it's too general:
> > > > anything stuck on the end is a suffix, but not necessarily
> > > > a filename extension. Suffixes are used for other purposes.
> > > Suffix is the correct term.
> > > File names in Linux are a character string of 255 chars. Again there are not file extensions in a Linux file name.
> > >
> > > People are conflating the issue.
> > >
> > > Read the code, code good.
> > So you've said five or six times already. The trouble is that it's
> > difficult to square this with documentation not only of the OS in
> > the widest sense, but also the linux kernel itself, which uses the
> > term extension.
> >
> > It's often stated, and has been in this thread, that the kernel uses
> > magic numbers at the start of executables rather than filename
> > extensions, and while this is true, it's not the only method.
> >
> > Take a look, for example, at this file (choose your version):
> >
> > linux-source-5.10/Documentation/admin-guide/binfmt-misc.rst
> > [ … ]
> >
> Where exactly is the variable defined in the kernel source that a
> file extension is defined
>
> filename is defined as a char "string" of 255 chars, so where is
> extension defined?
In fs/binfmt_misc.c (extracts below are from 5.10, which I happen to
have installed here):
// SPDX-License-Identifier: GPL-2.0-only
/*
* binfmt_misc.c
*
* Copyright (C) 1997 Richard Günther
*
* binfmt_misc detects binaries via a magic or filename extension and invokes
* a specified wrapper. See Documentation/admin-guide/binfmt-misc.rst for more details.
*/
typedef struct {
struct list_head list;
unsigned long flags; /* type, status, etc. */
int offset; /* offset of magic */
int size; /* size of magic/mask */
char *magic; /* magic or filename extension */
char *mask; /* mask, NULL for exact match */
const char *interpreter; /* filename of interpreter */
char *name;
struct dentry *dentry;
struct file *interp_file;
} Node;
/* Parse the 'type' field. */
switch (*p++) {
case 'E':
pr_debug("register: type: E (extension)\n");
e->flags = 1 << Enabled;
break;
case 'M':
pr_debug("register: type: M (magic)\n");
e->flags = (1 << Enabled) | (1 << Magic);
break;
default:
goto einval;
}
/* Handle the 'E' (extension) format. */
/* Skip the 'offset' field. */
p = strchr(p, del);
if (!p)
goto einval;
*p++ = '\0';
/* Parse the 'magic' field. */
e->magic = p;
p = strchr(p, del);
if (!p)
goto einval;
*p++ = '\0';
if (!e->magic[0] || strchr(e->magic, '/'))
goto einval;
pr_debug("register: extension: {%s}\n", e->magic);
if (!test_bit(Magic, &e->flags)) {
sprintf(dp, "extension .%s\n", e->magic);
} else {
dp += sprintf(dp, "offset %i\nmagic ", e->offset);
dp = bin2hex(dp, e->magic, e->size);
if (e->mask) {
dp += sprintf(dp, "\nmask ");
dp = bin2hex(dp, e->mask, e->size);
}
*dp++ = '\n';
*dp = '\0';
}
> Read the books on c programming, a filename is defines as a string of
> chars and in the case of linux 255 chars and the . is not special nor
> is anything following it. They are all just characters.
Relevance? Books on C? You did write "Read the code, code good."
Here's the actual code:
$ strings /lib/modules/5.10.0-26-amd64/kernel/fs/binfmt_misc.ko | grep -e 'extension' -e 'suffix'
extension .%s
register: extension: {%s}
binfmt_misc: register: type: E (extension)
binfmt_misc: register: extension: {%s}
register: type: E (extension)
$
Also: "I must be blind as I don't see extension anywhere".
> It's not easy to be me
Perhaps we can see why.
Cheers,
David.
Reply to: