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.