[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Image handling in mutt




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


Reply to: