Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #264642
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Newsgroups | linux.debian.user |
| Subject | Re: Image handling in mutt |
| Date | 2023-12-11 17:10 +0100 |
| Message-ID | <HJR10-cS3C-7@gated-at.bofh.it> (permalink) |
| References | <HJyhH-cGns-3@gated-at.bofh.it> <HJz46-cGE3-17@gated-at.bofh.it> <HJPVf-cRbE-1@gated-at.bofh.it> <HJQ4V-cRuJ-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Image handling in mutt Paul M Foster <paulf@quillandmouse.com> - 2023-12-08 18:00 +0100
Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-08 18:10 +0100
Re: Image handling in mutt Paul M Foster <paulf@quillandmouse.com> - 2023-12-08 22:50 +0100
Re: Image handling in mutt David <bouncingcats@gmail.com> - 2023-12-08 23:00 +0100
Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-08 23:10 +0100
Re: Image handling in mutt Greg Wooledge <greg@wooledge.org> - 2023-12-08 23:40 +0100
Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-08 23:50 +0100
Re: Image handling in mutt Greg Wooledge <greg@wooledge.org> - 2023-12-09 00:00 +0100
Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-09 00:10 +0100
Re: Image handling in mutt Greg Wooledge <greg@wooledge.org> - 2023-12-09 00:20 +0100
Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-09 00:30 +0100
Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-09 00:00 +0100
Re: Image handling in mutt John Hasler <john@sugarbit.com> - 2023-12-09 00:00 +0100
Re: Image handling in mutt Greg Wooledge <greg@wooledge.org> - 2023-12-09 00:00 +0100
Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-09 00:30 +0100
Re: Image handling in mutt Eric S Fraga <e.fraga@ucl.ac.uk> - 2023-12-09 09:50 +0100
Re: Image handling in mutt Curt <curty@free.fr> - 2023-12-10 17:20 +0100
Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-10 17:30 +0100
Re: Image handling in mutt songbird <songbird@anthive.com> - 2023-12-10 19:40 +0100
Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-10 19:50 +0100
Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-10 21:20 +0100
Re: Image handling in mutt songbird <songbird@anthive.com> - 2023-12-11 02:30 +0100
Re: Image handling in mutt debian-user@howorth.org.uk - 2023-12-11 16:30 +0100
Re: Image handling in mutt songbird <songbird@anthive.com> - 2023-12-11 21:20 +0100
Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 12:40 +0100
Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-11 13:30 +0100
Re: Image handling in mutt "Loris Bennett" <loris.bennett@fu-berlin.de> - 2023-12-11 14:10 +0100
Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-10 21:10 +0100
Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-10 22:00 +0100
Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 13:20 +0100
Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-11 13:40 +0100
Re: Image handling in mutt Arno Lehmann <al@its-lehmann.de> - 2023-12-11 13:50 +0100
Re: Image handling in mutt Greg Wooledge <greg@wooledge.org> - 2023-12-11 14:20 +0100
Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 15:10 +0100
Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-11 15:40 +0100
Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 16:20 +0100
Re: Image handling in mutt "Jeremy Nicoll" <jn.ml.dbi.73@letterboxes.org> - 2023-12-11 19:00 +0100
Re: Image handling in mutt jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-11 23:10 +0100
On file systems [was: Image handling in mutt] <tomas@tuxteam.de> - 2023-12-12 06:40 +0100
Re: On file systems "Thomas Schmitt" <scdbackup@gmx.net> - 2023-12-12 11:50 +0100
Re: Image handling in mutt Eric S Fraga <e.fraga@ucl.ac.uk> - 2023-12-11 13:50 +0100
Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 15:00 +0100
Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-11 15:20 +0100
Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 15:40 +0100
Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-11 15:50 +0100
Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-11 15:50 +0100
Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-11 16:00 +0100
Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-11 16:10 +0100
Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-11 17:10 +0100
Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-11 16:10 +0100
Re: Image handling in mutt Stefan Monnier <monnier@iro.umontreal.ca> - 2023-12-11 16:20 +0100
Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-11 16:30 +0100
Re: Image handling in mutt Zenaan Harkness <zenaan@gmail.com> - 2023-12-11 00:10 +0100
Re: Image handling in mutt Zenaan Harkness <zenaan@gmail.com> - 2023-12-11 01:20 +0100
Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-11 16:30 +0100
csiph-web