On file systems [was: Image handling in mutt]

[tomas]

On Tue, Dec 12, 2023 at 06:04:04AM +0800, jeremy ardley wrote:

[...]

> If you look at the NTFS file system [...]

> Underneath the hood of a NTFS file is alternate data streams (ADS). That is
> a single file can contain main different 'sub files' of completely different
> content type. Each ADS has metadata describing the stream.

I think the idea "was in the air" back then (mid-1980s), covering a wide
field between "rich file metadata" and several "streams" per file, cf.
Apple's HFS, which evolved into HFS+; NTFS is itself an evolution of
OS2's HPFs, etc, etc.

You also see, back then, increasing use of B and B+ trees in different
roles in file systems.

After all, designers moved from company to company and carried with them
ideas and teams. Companies were aggressively hiring people off other
companies.

It's actually risky to say "so and so had first this feature" without
deep research. Where do you put the limit between "file metadata" and
"file substream"? 65K? 4T? HP/UX implemented a file stream mechanism
on top of its Unix file system (those were directories which looked
like files), explicitly to support multi-architecture binaries. Remember
Apple's "fat binaries", which contained a binary for 68K and another
for PowerPC? Those were made with "forks", which was Apple's variant
of "several streams in one file". And so on.

Interesting times :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Image handling in mutt

[jeremy ardley]

On 12/12/23 01:49, Jeremy Nicoll wrote:

There's no concept of filetype in file systems used for the MVS side
of z/OS systems.  (These days there's also Unix/Linux environments
& of course they do have more familiar file naming structures.)



If you look at the NTFS file system - supported by most O/S including 
Debian, the file extension is only of use to user programs to help users 
select they type of files they want e.g. .jpg. It has no meaning at all 
to the applcations that use them.


Underneath the hood of a NTFS file is alternate data streams (ADS). That 
is a single file can contain main different 'sub files' of completely 
different content type. Each ADS has metadata describing the stream.


ADS were first conceived to provide say different language versions of a 
text file, but that is only an example. An ADS in a file could contain 
an executable as well as a text file. Theoretically you could also have 
a video stream and a subtitle stream and multiple audio streams, but 
that is usually better provides by container formats like ogg vorbis


In unixland file systems like ZFS have extended attributes but nothing 
like ADS

Re: Image handling in mutt

[songbird]

debian-u...@howorth.org.uk wrote:
> songbird  wrote:
>>  wrote:
>> > On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote:  
>> >>  wrote:  
>> 
>>   there is rarely a need to e-mail me directly.
>> 
>> >> ...  
>> >> > That's why I cringe when people name executables "foo.sh". What
>> >> > do you do when you decide to rewrite the thing in C (or Rust, or
>> >> > whatever)?
>> >> >
>> >> > Do you go over all calling sites and change the caller's code?  
>> >> 
>> >>   no, i would just consider it a transition or a change
>> >> in versions.  :)  
>> >
>> > Again. You have one script, say /usr/local/bin/ring-the-bells.sh
>> > You use it in several other scripts. If you now re-implement it
>> > in your favourite Pascal as ring-the-bells.pas or something, you
>> > go over all your executables and fix that?
>> >
>> > IMO an executable name should indicate /what/ an executable does,
>> > not /how/.  
>> 
>>   i'm fine with that, but i'm also capable enough to know
>> how to search through a code base to find all the strings
>> i might need to change.
>
> You make the anti-heroic assumption that your code is never used
> outside of your control (or specifically, outside of your code base).

  if someone else uses it then they can do what
they want with it.  i can only control my own local
system and that is all i am concerned about.

  in actual programming with libraries there are
these things called APIs and ABIs and both are 
usually documented and defined if it is important
enough and used enough.  IMO most of my code does
not reach that level of use.


>>   i just scanned a few of my projects and noted i do not
>> use the .sh extension much at all for the binaries/executables,
>> but parts of the code may have that extension.
>
> That's a fine choice, as long as none of the internals will be exposed
> externally, IMHO. Though I confess I do often add a .pl extension to
> filenames :(

  not something i'm worried about for sure.


> PS I suspect tomas sent mail to you for the same reason I nearly did,
> namely that you or your mailer explicitly asked for it with a reply-to
> header. Certainly my claws MUA interprets that as meaning you want a
> copy too.

  correct, so if you are going to reply to me personally
that is the right address to use, but since i interact
with this list via gmane and usenet a followup to me should
go to the list and not to me personally.

  i would assume that group reply is one that everyone
should be using automatically for mail list participation
using a mail client unless the person mentions they are
not subscribed and would like personal replies.


  songbird

Re: Image handling in mutt

[Jeremy Nicoll]

On Mon, 11 Dec 2023, at 13:16, Greg Wooledge wrote:

> 4) File extensions are used by programs on every operating system.

Certainly on many OSes, but not all.

They're not present on native RISC OS systems (as in ex-Acorn micros).
Filetype data IS stored, but it is in files' metadata.



There's no concept of filetype in file systems used for the MVS side
of z/OS systems.  (These days there's also Unix/Linux environments
& of course they do have more familiar file naming structures.)

By convention collections of separate files might all be kept in a set
very vaguely analagous to a directory - though with no parent
directory nor child sub-directories), known as a "PDS".  The name
of a PDS is fairly arbitrary (subject to installation conventions & 
security restrictions) & the names of files within ("members") also
have no real meaning unless an application chooses to interpret
their names in some special way.

One refers to a PDS as a whole by its name, eg "MY.SAMPLE.PDS"
& to a member within it, eg the file named "FRED", as
"MY.SAMPLE.PDS(FRED)".

While there are conventions for names of these PDSes, there's no
requirement that every file within, say "MY.SAMPLE.ASM" would
contain assembler source.  Often only some of the files would do
with others containing notes etc.

If a PDS's name looks like it might contain binary executables AND
it is actually used in a place where that would be expected, then you
can infer that it does do; you wouldn't find plain text notes, sample
data etc alongside the executables (because other characteristics
of those file sets allow them only to hold executables).

You cannot tell from a file's name whether it's held on disk or 
(virtual) tape or real tape, nor which device it's currently on.

-- 
Jeremy Nicoll - my opinions are my own.

Re: Image handling in mutt

[David Wright]

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 

Re: Image handling in mutt

[tomas]

On Mon, Dec 11, 2023 at 10:10:31AM -0500, Stefan Monnier wrote:

[...]

> I think what you're saying is that it would make sense to use
> a dedicated extension for executables, like, say, `.exe`,
> since "all users rely on it being" executable.

I'd prefer ".com", but hey ;-)

> FWIW, I agree, but this ship sailed a long time ago.
> 
> 
> Stefan "who likes types"

Yes, but I know your style well enough to know you'd never encode
the type in the variable name ;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Image handling in mutt

[David Wright]

On Mon 11 Dec 2023 at 10:07:28 (+1100), Zenaan Harkness wrote:
> > Second, how do I fix this so that mutt uses feh to display images?
> 
> Here is my mailcap entry, which works for me - had to deal with
> annoying filename munging by mutt, and getting the "close the viewer"
> bit working - this is quite a few years ago and now I can't even
> remember why the ; test=test -n "$DISPLAY" or the sleep are needed,
> but they were - heuristics annoy, but sometimes they are necessary:

I'm not familiar with the mutt filename munging problem etc. As for
test=test -n "$DISPLAY", I presume it's there to prevent trying to
run graphical commands on a text terminal, where DISPLAY is unset.

> image/*; (mv %s %s-\; feh -Z %s-\; rm -f %s-)& sleep 0.2s; test=test
> -n "$DISPLAY"

I've never trusted feh since the time when its default slideshow mode
had the astonishing behaviour of modifying the source file if you,
say, rotated the display of the image. They may have fixed it, but
I've stuck with alternatives.

I use:

  image/jpeg; /usr/bin/xli -quiet stdin; test=test -n "$DISPLAY"; 
description=JPEG Image
  image/png; /usr/bin/xli -quiet stdin; test=test -n "$DISPLAY"; 
description=PNG Image
  image/gif; /usr/bin/xli -quiet stdin; test=test -n "$DISPLAY"; 
description=GIF Image
  image/webp; convert webp:- jpeg:- | /usr/bin/xli -quiet stdin; test=test -n 
"$DISPLAY"; description=WEBP Image
  image/tiff; convert tiff:- jpeg:- | /usr/bin/xli -quiet stdin; test=test -n 
"$DISPLAY"; description=TIFF Image

> Similarly my mailcap entry for pdf files:
> 
> application/pdf; (mv %s %s-.pdf\; evince %s-.pdf 2\>\&1 \; rm -f
> %s-.pdf)& sleep 0.2s; test=test -n "$DISPLAY"
> image/pdf; /usr/bin/display-im6 %s; test=test -n "$DISPLAY"

Does evince need a mouse click to exit, and is that what you're
referring to with ‘getting the "close the viewer" bit working’?
That would rule it out for me.

I use:

  application/pdf; /usr/bin/xpdf -fullscreen %s; test=test -n "$DISPLAY"; 
description=Portable Document Format; nametemplate=%s.pdf

> Finally, occasionally I need to cleanly dump html, this one seems a bit 
> simpler:
> 
> text/html; lynx -stdin -dump -width=$COLS; copiousoutput; compose=vim %s

I prefer to navigate any structure, with:

  text/html; /usr/bin/lynx -force-html -localhost -stdin

and I find this useful very occasionally:

  text/markdown; /usr/bin/pandoc %s | /usr/bin/lynx -localhost -stdin

Adding -localhost prevents any external links from working.

Cheers,
David.

Re: Image handling in mutt

[debian-user]

songbird  wrote:
>  wrote:
> > On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote:  
> >>  wrote:  
> 
>   there is rarely a need to e-mail me directly.
> 
> >> ...  
> >> > That's why I cringe when people name executables "foo.sh". What
> >> > do you do when you decide to rewrite the thing in C (or Rust, or
> >> > whatever)?
> >> >
> >> > Do you go over all calling sites and change the caller's code?  
> >> 
> >>   no, i would just consider it a transition or a change
> >> in versions.  :)  
> >
> > Again. You have one script, say /usr/local/bin/ring-the-bells.sh
> > You use it in several other scripts. If you now re-implement it
> > in your favourite Pascal as ring-the-bells.pas or something, you
> > go over all your executables and fix that?
> >
> > IMO an executable name should indicate /what/ an executable does,
> > not /how/.  
> 
>   i'm fine with that, but i'm also capable enough to know
> how to search through a code base to find all the strings
> i might need to change.

You make the anti-heroic assumption that your code is never used
outside of your control (or specifically, outside of your code base).

>   i just scanned a few of my projects and noted i do not
> use the .sh extension much at all for the binaries/executables,
> but parts of the code may have that extension.

That's a fine choice, as long as none of the internals will be exposed
externally, IMHO. Though I confess I do often add a .pl extension to
filenames :(

PS I suspect tomas sent mail to you for the same reason I nearly did,
namely that you or your mailer explicitly asked for it with a reply-to
header. Certainly my claws MUA interprets that as meaning you want a
copy too.

Re: Image handling in mutt

[Vincent Lefevre]

On 2023-12-11 09:34:09 -0500, Pocket wrote:
> On 12/11/23 09:04, Vincent Lefevre wrote:
> > On 2023-12-11 08:16:30 -0500, Greg Wooledge wrote:
> > > 2) When *receiving* email, mutt will use the sender's MIME type label
> > > to decide how to deal with the attachment.
> > But the notion of filename extension is even used in this context too.
> > Quoting the Mutt manual:
> > 
> > 
> > nametemplate=
> >This field specifies the format for the file denoted by %s in
> >the command fields. Certain programs will require a certain
> >file extension, for instance, to correctly view a file. For
> >instance, lynx will only interpret a file as text/html if the
> >file ends in .html. So, you would specify lynx as a text/html
> >viewer with a line in the mailcap file like:
> > 
> > text/html; lynx %s; nametemplate=%s.html
> > 
> > 
> > This is due to
> > 
> > > 3) Many other programs besides mutt will also use file extensions to
 
> > > determine how to deal with input files.
> 
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:struct 
> filename {
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:static_assert(offsetof(struct
>  filename, iname) % sizeof(long) == 0);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
> file *file_open_name(struct filename *, int, umode_t);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
> filename *getname_flags(const char __user *, int, int *);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
> filename *getname_uflags(const char __user *, int);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
> filename *getname(const char __user *);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
> filename *getname_kernel(const char *);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern void 
> putname(struct filename *name);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs_context.h:  
> struct filename *name;
> 
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_chdir(const char *filename);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_chroot(const char *filename);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_chown(const char *filename, uid_t user, gid_t group, int flags);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_chmod(const char *filename, umode_t mode);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_eaccess(const char *filename);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_stat(const char *filename, struct kstat *stat, int flags);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_mknod(const char *filename, umode_t mode, unsigned int dev);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_utimes(char *filename, struct timespec64 *ts);
> 
> I must be blind as I don't see extension anywhere

We're talking about programs (Mutt and others). You're quoting things
from the Linux kernel.

You probably won't see anything about the filename extensions either
in the low-level part of the MS Windows code either.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Image handling in mutt

[Stefan Monnier]

> (Note that I'd even make a difference: where the implementation matters,
> e.g. some shell code to be sourced in, I'd be more lenient in calling
> the thing ".sh": after all, its users rely on it being shell code. When
> you can change the implementation without changing the function, e.g.
> a shell script/executable -- I am decidedly against slapping a suffix
> on the name.

I think what you're saying is that it would make sense to use
a dedicated extension for executables, like, say, `.exe`,
since "all users rely on it being" executable.

FWIW, I agree, but this ship sailed a long time ago.


Stefan "who likes types"

Re: Image handling in mutt

[Pocket]

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 

Re: Image handling in mutt

[tomas]

On Mon, Dec 11, 2023 at 08:52:37AM -0600, David Wright wrote:
> On Sun 10 Dec 2023 at 15:51:02 (-0500), Pocket wrote:

[...]

> > 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.

:-)

I'd tend to the maxim "all generalizations suck".

I do agree that encoding file type in the file name is an antipattern
(and tend to avoid that whenever possible). That said, it's true that
there are more than enough user space applications (and as you showed,
even kernel space ones) where that antipattern crept in.

I think it's there to stay. But it is good to put some counterpressure.

(Note that I'd even make a difference: where the implementation matters,
e.g. some shell code to be sourced in, I'd be more lenient in calling
the thing ".sh": after all, its users rely on it being shell code. When
you can change the implementation without changing the function, e.g.
a shell script/executable -- I am decidedly against slapping a suffix
on the name.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Image handling in mutt

[David Wright]

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`` 

Re: Image handling in mutt

[Pocket]

On 12/11/23 09:34, Vincent Lefevre wrote:

On 2023-12-11 15:16:57 +0100, to...@tuxteam.de wrote:

On Mon, Dec 11, 2023 at 02:58:01PM +0100, Vincent Lefevre wrote:

I do not care about the "microsoft world", and I doubt that this is
required there at the low level (what would be the equivalent of the
Linux kernel) [...]

This depends: the FAT file system (which still is the lowest common
denominator) actually reserves 8 chars for the file name and three
for the --ahem-- extension. The dot isn't encoded explicitly on-disk.

This is unrelated to the OS. The FAT file system may be used also
under Linux (e.g. because this is what some memory sticks have),
and there are the same limitations.



So you are implying that you can discard file extensions with MS-DOS 6.22?

That is false, from before Win7 MS operating systems REQUIRED a file 
extension to determine file type.


Linux has no such requirement.

--
It's not easy to be me

Re: Image handling in mutt

[tomas]

On Mon, Dec 11, 2023 at 03:34:28PM +0100, Vincent Lefevre wrote:
> On 2023-12-11 15:16:57 +0100, to...@tuxteam.de wrote:
> > On Mon, Dec 11, 2023 at 02:58:01PM +0100, Vincent Lefevre wrote:
> > > I do not care about the "microsoft world", and I doubt that this is
> > > required there at the low level (what would be the equivalent of the
> > > Linux kernel) [...]
> > 
> > This depends: the FAT file system (which still is the lowest common
> > denominator) actually reserves 8 chars for the file name and three
> > for the --ahem-- extension. The dot isn't encoded explicitly on-disk.
> 
> This is unrelated to the OS. The FAT file system may be used also
> under Linux (e.g. because this is what some memory sticks have),
> and there are the same limitations.

You conveniently snipped the OS part. Of course this (and the absence
of hard links) is a limitation of the file system.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Image handling in mutt

[Vincent Lefevre]

On 2023-12-11 15:16:57 +0100, to...@tuxteam.de wrote:
> On Mon, Dec 11, 2023 at 02:58:01PM +0100, Vincent Lefevre wrote:
> > I do not care about the "microsoft world", and I doubt that this is
> > required there at the low level (what would be the equivalent of the
> > Linux kernel) [...]
> 
> This depends: the FAT file system (which still is the lowest common
> denominator) actually reserves 8 chars for the file name and three
> for the --ahem-- extension. The dot isn't encoded explicitly on-disk.

This is unrelated to the OS. The FAT file system may be used also
under Linux (e.g. because this is what some memory sticks have),
and there are the same limitations.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Image handling in mutt

[Pocket]

On 12/11/23 09:04, Vincent Lefevre wrote:

On 2023-12-11 08:16:30 -0500, Greg Wooledge wrote:

2) When *receiving* email, mutt will use the sender's MIME type label
to decide how to deal with the attachment.

But the notion of filename extension is even used in this context too.
Quoting the Mutt manual:


nametemplate=
   This field specifies the format for the file denoted by %s in
   the command fields. Certain programs will require a certain
   file extension, for instance, to correctly view a file. For
   instance, lynx will only interpret a file as text/html if the
   file ends in .html. So, you would specify lynx as a text/html
   viewer with a line in the mailcap file like:

text/html; lynx %s; nametemplate=%s.html


This is due to


3) Many other programs besides mutt will also use file extensions to
determine how to deal with input files.


/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:struct filename 
{
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:static_assert(offsetof(struct
 filename, iname) % sizeof(long) == 0);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
file *file_open_name(struct filename *, int, umode_t);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
filename *getname_flags(const char __user *, int, int *);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
filename *getname_uflags(const char __user *, int);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
filename *getname(const char __user *);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
filename *getname_kernel(const char *);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern void 
putname(struct filename *name);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs_context.h:
struct filename *name;

/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int 
__init init_chdir(const char *filename);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int 
__init init_chroot(const char *filename);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int 
__init init_chown(const char *filename, uid_t user, gid_t group, int flags);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int 
__init init_chmod(const char *filename, umode_t mode);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int 
__init init_eaccess(const char *filename);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int 
__init init_stat(const char *filename, struct kstat *stat, int flags);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int 
__init init_mknod(const char *filename, umode_t mode, unsigned int dev);
/usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int 
__init init_utimes(char *filename, struct timespec64 *ts);


I must be blind as I don't see extension anywhere


--
It's not easy to be me

Re: Image handling in mutt

[tomas]

On Mon, Dec 11, 2023 at 02:58:01PM +0100, Vincent Lefevre wrote:

[...]

> I do not care about the "microsoft world", and I doubt that this is
> required there at the low level (what would be the equivalent of the
> Linux kernel) [...]

This depends: the FAT file system (which still is the lowest common
denominator) actually reserves 8 chars for the file name and three
for the --ahem-- extension. The dot isn't encoded explicitly on-disk.

DOS itself treats some extensions especially (.BAT, .COM, .EXE);
since Windows > 3.1 I (luckily!) lost track of whatever shenanigans
Microsoft has been up to.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Image handling in mutt

[Vincent Lefevre]

On 2023-12-11 08:16:30 -0500, Greg Wooledge wrote:
> 2) When *receiving* email, mutt will use the sender's MIME type label
>to decide how to deal with the attachment.

But the notion of filename extension is even used in this context too.
Quoting the Mutt manual:


   nametemplate=
  This field specifies the format for the file denoted by %s in
  the command fields. Certain programs will require a certain
  file extension, for instance, to correctly view a file. For
  instance, lynx will only interpret a file as text/html if the
  file ends in .html. So, you would specify lynx as a text/html
  viewer with a line in the mailcap file like:

text/html; lynx %s; nametemplate=%s.html


This is due to

> 3) Many other programs besides mutt will also use file extensions to
>determine how to deal with input files.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Image handling in mutt

[Vincent Lefevre]

On 2023-12-11 07:32:30 -0500, Pocket wrote:
> 
> On 12/11/23 07:12, Vincent Lefevre wrote:
> > On 2023-12-10 15:51:02 -0500, Pocket wrote:
> > > On Dec 10, 2023, at 3:05 PM, David Wright  
> > > wrote:
> > > > ¹ 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.
> > A filename extension is a suffix, but a suffix (e.g. as in POSIX)
> > is not necessarily a filename extension.
> 
> Not in the microsoft world, it is REQUIRED and that is what the OS
> needs to tell what kind of file it is dealing with.  Unix/Linux has
> no resrictions.

I do not care about the "microsoft world", and I doubt that this is
required there at the low level (what would be the equivalent of the
Linux kernel). The filename extension matters at a high level, e.g.
to select which application should be run, but similar choices are
also done under Linux, where this is implemented by utilities,
libraries, or applications themselves. There are other methods under
Linux, such as content sniffing (the method used by "file"), which
has advantages, but also drawbacks (the file needs to be readable,
and mainly for the various text formats, sniffing is unreliable;
good luck with the diff and json formats, for instance).

And even when the application is known, e.g. when the file type is
given by a MIME type, a filename extension may be necessary. See
the various "nametemplate" fields in /etc/mailcap, for instance.

> > For instance:
> > 
> > $ basename foobar bar
> > foo
> > 
> > Here, "bar" is a suffix, but it does not have the form of a
> > filename extension.
> 
> No bar is part of the filespec

No, read the POSIX standard:

  SYNOPSIS
basename string [suffix]

This is explicitly called suffix.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Image handling in mutt

[Greg Wooledge]

On Mon, Dec 11, 2023 at 01:41:09PM +0100, Arno Lehmann wrote:
> I do not see the relevance of the discussion about file name extensions,
> types, suffixes for Debian. Even more so as you are at the stage of
> repeating statements without bringing new value. In fact, there seems to be
> no goal with this thread.
> 
> 
> I would ask you to continue this discussion elsewhere.

It's on topic, so there's no call to ask for the discussion to be
discontinued here.

The facts are pretty simple:

1) When *sending* email, mutt uses the file's extension to decide which
   MIME type label to give the attached file.

2) When *receiving* email, mutt will use the sender's MIME type label
   to decide how to deal with the attachment.

3) Many other programs besides mutt will also use file extensions to
   determine how to deal with input files.

4) File extensions are used by programs on every operating system.  This
   has been the case since before MS-DOS existed; it continues to this
   day; and it will continue for the foreseeable future.

5) Kernels don't know or care about filename extensions.  However,
   confusing a kernel with a whole operating system is a mistake.
   Programs such as file managers are part of the operating system,
   and file managers almost always care about file extensions.

Re: Image handling in mutt

[Loris Bennett]

David  writes:

> Hi, the filename extension is usually irrelevant on Linux, because
> Linux tools typically
> use the standard 'file' command to inspect the content of the
> fileinstead of relying on
> the filename to indicate content.

It is very often not irrelevant for files that you might want to edit.
Emacs (and I assume many editors) can provide a great deal of support
for specific types of file and, by default, uses the extension (the
term used in the Emacs documentation) to determine the file type.

Cheers,

Loris
  
-- 
This signature is currently under constuction.

Re: Image handling in mutt

[Eric S Fraga]

On Monday, 11 Dec 2023 at 07:32, Pocket wrote:
> No it is microsoft non sense

I'm not an MS fanboi but please stop blaming MS for something they did
not invent!

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2

Re: Image handling in mutt

[Arno Lehmann]

All,

I do not see the relevance of the discussion about file name extensions, 
types, suffixes for Debian. Even more so as you are at the stage of 
repeating statements without bringing new value. In fact, there seems to 
be no goal with this thread.



I would ask you to continue this discussion elsewhere.

Thanks,

Arno


--
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

Re: Image handling in mutt

[Pocket]

On 12/11/23 07:12, Vincent Lefevre wrote:

On 2023-12-10 15:51:02 -0500, Pocket wrote:

On Dec 10, 2023, at 3:05 PM, David Wright  wrote:

¹ 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.

A filename extension is a suffix, but a suffix (e.g. as in POSIX)
is not necessarily a filename extension.


Not in the microsoft world, it is REQUIRED and that is what the OS needs 
to tell what kind of file it is dealing with.  Unix/Linux has no 
resrictions.




For instance:

$ basename foobar bar
foo

Here, "bar" is a suffix, but it does not have the form of a
filename extension.


No bar is part of the filespec




So the notion of "filename extension" is more specific


No it is microsoft non sense

https://www.man7.org/linux/man-pages/man4/magic.4.html

https://www.geeksforgeeks.org/working-with-magic-numbers-in-linux/

https://www.darwinsys.com/file/

Re: Image handling in mutt

[Pocket]

On 12/11/23 06:39, Vincent Lefevre wrote:

On 2023-12-08 17:06:15 -0500, Pocket wrote:

On 12/8/23 16:53, David wrote:

Hi, the filename extension is usually irrelevant on Linux, because
Linux tools typically
use the standard 'file' command to inspect the content of the
fileinstead of relying on
the filename to indicate content.

In Unix and Linux there isn't a file extension, that is a microsoft
invention.

More and more applications under Linux, like atril and lynx, care
about the file extension.


It is a suffix not extension.

Re: Image handling in mutt

[Vincent Lefevre]

On 2023-12-10 15:51:02 -0500, Pocket wrote:
> On Dec 10, 2023, at 3:05 PM, David Wright  wrote:
> > ¹ 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. 

A filename extension is a suffix, but a suffix (e.g. as in POSIX)
is not necessarily a filename extension.

For instance:

$ basename foobar bar
foo

Here, "bar" is a suffix, but it does not have the form of a
filename extension.

So the notion of "filename extension" is more specific.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Image handling in mutt

[Vincent Lefevre]

On 2023-12-08 17:06:15 -0500, Pocket wrote:
> On 12/8/23 16:53, David wrote:
> > Hi, the filename extension is usually irrelevant on Linux, because
> > Linux tools typically
> > use the standard 'file' command to inspect the content of the
> > fileinstead of relying on
> > the filename to indicate content.
> 
> In Unix and Linux there isn't a file extension, that is a microsoft
> invention.

More and more applications under Linux, like atril and lynx, care
about the file extension.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Image handling in mutt

[songbird]

 wrote:
> On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote:
>>  wrote:

  there is rarely a need to e-mail me directly.

>> ...
>> > That's why I cringe when people name executables "foo.sh". What do you
>> > do when you decide to rewrite the thing in C (or Rust, or whatever)?
>> >
>> > Do you go over all calling sites and change the caller's code?
>> 
>>   no, i would just consider it a transition or a change
>> in versions.  :)
>
> Again. You have one script, say /usr/local/bin/ring-the-bells.sh
> You use it in several other scripts. If you now re-implement it
> in your favourite Pascal as ring-the-bells.pas or something, you
> go over all your executables and fix that?
>
> IMO an executable name should indicate /what/ an executable does,
> not /how/.

  i'm fine with that, but i'm also capable enough to know
how to search through a code base to find all the strings
i might need to change.

  i just scanned a few of my projects and noted i do not
use the .sh extension much at all for the binaries/executables,
but parts of the code may have that extension.


>>   i was always glad when people wrote descriptive names
>> for their programs instead of "f" or "f(x)".
>
> This is something totally different. Call the function by
> what it does, but -- again -- not by how.

  :)


>>   since my first major programs were written in Assembler
>> Pascal and C whatever extensions needed for those were 
>> used, i didn't see it as any fault.
>
> It is your prerogative, of course. I'm happy that ls is ls
> and git, git (not ls.i-was-implemented-in-c or something).

  sure.


  songbird

Re: Image handling in mutt

[Zenaan Harkness]

> Finally, occasionally I need to cleanly dump html, this one seems a bit
> simpler:
>
> text/html; lynx -stdin -dump -width=$COLS; copiousoutput; compose=vim %s

I meant "cleanly _view_ html ..."

Re: Image handling in mutt

[Zenaan Harkness]

> Second, how do I fix this so that mutt uses feh to display images?

Here is my mailcap entry, which works for me - had to deal with
annoying filename munging by mutt, and getting the "close the viewer"
bit working - this is quite a few years ago and now I can't even
remember why the ; test=test -n "$DISPLAY" or the sleep are needed,
but they were - heuristics annoy, but sometimes they are necessary:

image/*; (mv %s %s-\; feh -Z %s-\; rm -f %s-)& sleep 0.2s; test=test
-n "$DISPLAY"

Similarly my mailcap entry for pdf files:

application/pdf; (mv %s %s-.pdf\; evince %s-.pdf 2\>\&1 \; rm -f
%s-.pdf)& sleep 0.2s; test=test -n "$DISPLAY"
image/pdf; /usr/bin/display-im6 %s; test=test -n "$DISPLAY"

Finally, occasionally I need to cleanly dump html, this one seems a bit simpler:

text/html; lynx -stdin -dump -width=$COLS; copiousoutput; compose=vim %s

Re: Image handling in mutt

[Pocket]

Sent from my iPad

> 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.

> 
> Cheers,
> David.
> 

Re: Image handling in mutt

[David Wright]

On Sun 10 Dec 2023 at 19:48:29 (+0100), to...@tuxteam.de wrote:
> On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote:
> >  wrote:
> > ...
> > > That's why I cringe when people name executables "foo.sh". What do you
> > > do when you decide to rewrite the thing in C (or Rust, or whatever)?
> > >
> > > Do you go over all calling sites and change the caller's code?
> > 
> >   no, i would just consider it a transition or a change
> > in versions.  :)
> 
> Again. You have one script, say /usr/local/bin/ring-the-bells.sh
> You use it in several other scripts. If you now re-implement it
> in your favourite Pascal as ring-the-bells.pas or something, you
> go over all your executables and fix that?

I've done that sort of thing, generally between bash and python.
It's so simple to implement with a symlink, ring-the-bells, that
points to the preferred version.

But there's some topic drift here. Most people are emailing
documents rather than executables most of the time. Should
I assume this disapproval of metadata in the filename doesn't
apply to them?

> IMO an executable name should indicate /what/ an executable does,
> not /how/.

AIUI executables fall into a different class, as the kernel can
recognise them by their magic number and take account of that.
You can't do that with the metadata inside, say, a PDF.

Cheers,
David.

Re: Image handling in mutt

[David Wright]

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.

Cheers,
David.

Re: Image handling in mutt

[tomas]

On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote:
>  wrote:
> ...
> > That's why I cringe when people name executables "foo.sh". What do you
> > do when you decide to rewrite the thing in C (or Rust, or whatever)?
> >
> > Do you go over all calling sites and change the caller's code?
> 
>   no, i would just consider it a transition or a change
> in versions.  :)

Again. You have one script, say /usr/local/bin/ring-the-bells.sh
You use it in several other scripts. If you now re-implement it
in your favourite Pascal as ring-the-bells.pas or something, you
go over all your executables and fix that?

IMO an executable name should indicate /what/ an executable does,
not /how/.

>   i was always glad when people wrote descriptive names
> for their programs instead of "f" or "f(x)".

This is something totally different. Call the function by
what it does, but -- again -- not by how.

>   since my first major programs were written in Assembler
> Pascal and C whatever extensions needed for those were 
> used, i didn't see it as any fault.

It is your prerogative, of course. I'm happy that ls is ls
and git, git (not ls.i-was-implemented-in-c or something).

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Image handling in mutt

[songbird]

 wrote:
...
> That's why I cringe when people name executables "foo.sh". What do you
> do when you decide to rewrite the thing in C (or Rust, or whatever)?
>
> Do you go over all calling sites and change the caller's code?

  no, i would just consider it a transition or a change
in versions.  :)

  i was always glad when people wrote descriptive names
for their programs instead of "f" or "f(x)".

  since my first major programs were written in Assembler
Pascal and C whatever extensions needed for those were 
used, i didn't see it as any fault.


  songbird

Re: Image handling in mutt

[tomas]

On Sun, Dec 10, 2023 at 04:15:22PM -, Curt wrote:
> On 2023-12-09, Eric S Fraga  wrote:
> > On Friday,  8 Dec 2023 at 17:06, Pocket wrote:
> >> In Unix and Linux there isn't a file extension, that is a microsoft
> >> invention.
> >
> > Predates MS by years.  Systems like RSTS/E on PDP-11s, just to name one.
> 
> They certainly are convenient. 

When they aren't a lie. Remember those "foo.jpg.exe"?

I always consider putting metadata in a file name a "design smell" [1].

That's why I cringe when people name executables "foo.sh". What do you
do when you decide to rewrite the thing in C (or Rust, or whatever)?

Do you go over all calling sites and change the caller's code?

Cheers

[1] https://en.wikipedia.org/wiki/Code_smell
-- 
t


signature.asc
Description: PGP signature

Re: Image handling in mutt

[Curt]

On 2023-12-09, Eric S Fraga  wrote:
> On Friday,  8 Dec 2023 at 17:06, Pocket wrote:
>> In Unix and Linux there isn't a file extension, that is a microsoft
>> invention.
>
> Predates MS by years.  Systems like RSTS/E on PDP-11s, just to name one.

They certainly are convenient. 

I must be stupid or something.

Re: Image handling in mutt

[Eric S Fraga]

On Friday,  8 Dec 2023 at 17:06, Pocket wrote:
> In Unix and Linux there isn't a file extension, that is a microsoft
> invention.

Predates MS by years.  Systems like RSTS/E on PDP-11s, just to name one.
-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2

Re: Image handling in mutt

[Pocket]

On 12/8/23 17:55, Greg Wooledge wrote:

On Fri, Dec 08, 2023 at 04:50:04PM -0600, John Hasler wrote:

Greg writes:

cc(1) and make(1) would like to have a talk with you.

Those are applications and can do whatever they want.  The OS does not
care about extensions.

What do you consider "the OS" to be, then?



https://www.britannica.com/technology/operating-system

https://en.wikipedia.org/wiki/Operating_system

https://www.geeksforgeeks.org/what-is-an-operating-system/





--
It's not easy to be me

Re: Image handling in mutt

[Pocket]

On 12/8/23 18:17, Greg Wooledge wrote:

On Fri, Dec 08, 2023 at 05:59:58PM -0500, Pocket wrote:

On 12/8/23 17:54, Greg Wooledge wrote:

cc(1) looks at the file extension to decide what kind of content each
named argument file is expected to contain.

No it looks for a suffix

So Debian files have "suffixes" and Windows files have "extensions",
and they're identical in form and function, but you use different labels
for them?  OK then.


No "extensions" are required in ms operation systems.

A file spec in Unix/Linux is a string of 255 characters

look it up





rename a jpeg to farts, linux still knows it is a jpeg

Why would the *kernel* know any such thing?  Kernels do not care about
graphical file types.


--
It's not easy to be me

Re: Image handling in mutt

[Greg Wooledge]

On Fri, Dec 08, 2023 at 05:59:58PM -0500, Pocket wrote:
> On 12/8/23 17:54, Greg Wooledge wrote:
> > cc(1) looks at the file extension to decide what kind of content each
> > named argument file is expected to contain.

> No it looks for a suffix

So Debian files have "suffixes" and Windows files have "extensions",
and they're identical in form and function, but you use different labels
for them?  OK then.

> rename a jpeg to farts, linux still knows it is a jpeg

Why would the *kernel* know any such thing?  Kernels do not care about
graphical file types.

Re: Image handling in mutt

[mick.crane]

On 2023-12-08 22:55, Greg Wooledge wrote:

On Fri, Dec 08, 2023 at 04:50:04PM -0600, John Hasler wrote:

Greg writes:
> cc(1) and make(1) would like to have a talk with you.

Those are applications and can do whatever they want.  The OS does not
care about extensions.


What do you consider "the OS" to be, then?


that's a great question
mick

Re: Image handling in mutt

[Pocket]

On 12/8/23 17:54, Greg Wooledge wrote:

On Fri, Dec 08, 2023 at 05:41:57PM -0500, Pocket wrote:

On 12/8/23 17:31, Greg Wooledge wrote:

On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote:

In Unix and Linux there isn't a file extension, that is a microsoft
invention.

cc(1) and make(1) would like to have a talk with you.


Linux/Unix filenaming specs would like to inform you.

file specs/naming i Unix and Linux are 355 characters and nothing more.

I am surprised you don't know that

cc(1) looks at the file extension to decide what kind of content each
named argument file is expected to contain.  A .c file is expected to
contain C language source code; a .o file is expected to contain object
code; a .s file is expected to contain assembly language source code;
and so on.  It invokes the compiler, the assembler, and/or the linker
depending on what kinds of files it has been given.



No it looks for a suffix




make(1) lets you define a rule for converting an input file with extension
E1 to an output file with extension E2.  These rules will be applied in
the absence of specific overrides.  If you define a rule like ".xx.yy:"
then make will use this to turn any *.xx file into a matching *.yy file.
Then you can type, for example, "make frog.yy" and it will look for
frog.xx and frog.yy, compare their timestamps, and if needed, apply your
custom rule to generate the frog.yy file.

While I'm giving examples, there's also Apache, which decides what
Content-type header to generate for a given static file based on its
extension.  I would imagine other web servers do the same thing.



Apache is an application that looks for a file suffix



And hey, I'm using mutt to compose and send this email.  If I were to
attach a file to this message, mutt would look at its extension to
decide what MIME type to give it.


rename a jpeg to farts, linux still knows it is a jpeg




Your notion that "most Unix programs use file(1) output to decide a file's
content" is simply not universal.  I don't even think it's *common*,
especially given how inconsistent file's output is.  Most programs
that need to determine content types dynamically look at extensions.
Even on Unix.


Non sense

--

It's not easy to be me

Re: Image handling in mutt

[Greg Wooledge]

On Fri, Dec 08, 2023 at 04:50:04PM -0600, John Hasler wrote:
> Greg writes:
> > cc(1) and make(1) would like to have a talk with you.
> 
> Those are applications and can do whatever they want.  The OS does not
> care about extensions.

What do you consider "the OS" to be, then?

Re: Image handling in mutt

[Greg Wooledge]

On Fri, Dec 08, 2023 at 05:41:57PM -0500, Pocket wrote:
> 
> On 12/8/23 17:31, Greg Wooledge wrote:
> > On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote:
> > > In Unix and Linux there isn't a file extension, that is a microsoft
> > > invention.
> > cc(1) and make(1) would like to have a talk with you.
> > 
> Linux/Unix filenaming specs would like to inform you.
> 
> file specs/naming i Unix and Linux are 355 characters and nothing more.
> 
> I am surprised you don't know that

cc(1) looks at the file extension to decide what kind of content each
named argument file is expected to contain.  A .c file is expected to
contain C language source code; a .o file is expected to contain object
code; a .s file is expected to contain assembly language source code;
and so on.  It invokes the compiler, the assembler, and/or the linker
depending on what kinds of files it has been given.

make(1) lets you define a rule for converting an input file with extension
E1 to an output file with extension E2.  These rules will be applied in
the absence of specific overrides.  If you define a rule like ".xx.yy:"
then make will use this to turn any *.xx file into a matching *.yy file.
Then you can type, for example, "make frog.yy" and it will look for
frog.xx and frog.yy, compare their timestamps, and if needed, apply your
custom rule to generate the frog.yy file.

While I'm giving examples, there's also Apache, which decides what
Content-type header to generate for a given static file based on its
extension.  I would imagine other web servers do the same thing.

And hey, I'm using mutt to compose and send this email.  If I were to
attach a file to this message, mutt would look at its extension to
decide what MIME type to give it.

Your notion that "most Unix programs use file(1) output to decide a file's
content" is simply not universal.  I don't even think it's *common*,
especially given how inconsistent file's output is.  Most programs
that need to determine content types dynamically look at extensions.
Even on Unix.

Re: Image handling in mutt

[Pocket]

On 12/8/23 17:41, Pocket wrote:


On 12/8/23 17:31, Greg Wooledge wrote:

On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote:

In Unix and Linux there isn't a file extension, that is a microsoft
invention.

cc(1) and make(1) would like to have a talk with you.


Linux/Unix filenaming specs would like to inform you.

file specs/naming i Unix and Linux are 355 characters and nothing more.



file specs/naming in Unix and Linux are 255 characters and nothing more.




I am surprised you don't know that



--
It's not easy to be me

Re: Image handling in mutt

[John Hasler]

Greg writes:
> cc(1) and make(1) would like to have a talk with you.

Those are applications and can do whatever they want.  The OS does not
care about extensions.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: Image handling in mutt

[Pocket]

On 12/8/23 17:31, Greg Wooledge wrote:

On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote:

In Unix and Linux there isn't a file extension, that is a microsoft
invention.

cc(1) and make(1) would like to have a talk with you.


Linux/Unix filenaming specs would like to inform you.

file specs/naming i Unix and Linux are 355 characters and nothing more.

I am surprised you don't know that


--
It's not easy to be me

Re: Image handling in mutt

[Greg Wooledge]

On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote:
> In Unix and Linux there isn't a file extension, that is a microsoft
> invention.

cc(1) and make(1) would like to have a talk with you.

Re: Image handling in mutt

[Pocket]

On 12/8/23 16:53, David wrote:

On Fri, 8 Dec 2023 at 21:45, 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, 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?

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.

Hi, the filename extension is usually irrelevant on Linux, because
Linux tools typically
use the standard 'file' command to inspect the content of the
fileinstead of relying on
the filename to indicate content.



In Unix and Linux there isn't a file extension, that is a microsoft 
invention.


Unix and Linux filespecs are just a bunch of characters

https://www.linfo.org/file_name.html

The period in a linux filespec is just a period and nothing more




What is more likely important is that the keywords in the output of
'file '
command are correctly specified in your desired configuration.


--
It's not easy to be me

Re: Image handling in mutt

[David]

On Fri, 8 Dec 2023 at 21:45, 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, 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?
> > >
> > > 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.

Hi, the filename extension is usually irrelevant on Linux, because
Linux tools typically
use the standard 'file' command to inspect the content of the
fileinstead of relying on
the filename to indicate content.

What is more likely important is that the keywords in the output of
'file '
command are correctly specified in your desired configuration.

Re: Image handling in mutt

[Paul M Foster]

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, 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?
> > 
> > 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.

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

Re: Image handling in mutt

[David Wright]

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, 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?
> 
> Second, how do I fix this so that mutt uses feh to display images?

Cheers,
David.

Image handling in mutt

[Paul M Foster]

Folks:

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, and
set an entry in there for image/jpg to point to /usr/bin/feh. I've even set
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?

Second, how do I fix this so that mutt uses feh to display images?

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster