Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #264629
| From | Pocket <pocket@columbus.rr.com> |
|---|---|
| Newsgroups | linux.debian.user |
| Subject | Re: Image handling in mutt |
| Date | 2023-12-11 16:10 +0100 |
| Message-ID | <HJQ4V-cRuJ-13@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> |
| Organization | linux.* mail to news gateway |
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 > > Kernel Support for miscellaneous Binary Formats (binfmt_misc) > ============================================================= > > This Kernel feature allows you to invoke almost (for restrictions > see below) every program by simply typing its name in the shell. > This includes for example compiled Java(TM), Python or Emacs programs. > > To achieve this you must tell binfmt_misc which interpreter has to > be invoked with which binary. Binfmt_misc recognises the binary-type > by matching some bytes at the beginning of the file with a magic > byte sequence (masking out specified bits) you have supplied. > Binfmt_misc can also recognise a filename extension aka ``.com`` > or ``.exe``. > > [ … ] > > ``magic`` > is the byte sequence binfmt_misc is matching for. The magic string > may contain hex-encoded characters like ``\x0a`` or ``\xA4``. Note > that you must escape any NUL bytes; parsing halts at the first one. > In a shell environment you might have to write ``\\x0a`` to prevent > the shell from eating your ``\``. > If you chose filename extension matching, this is the extension to be > recognised (without the ``.``, the ``\x0a`` specials are not allowed). > Extension matching is case sensitive, and slashes ``/`` are not allowed! > > Cheers, > David. > 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? 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. -- It's not easy to be me
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