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↑↑↑ try jpeg
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?
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↑↑↑ try jpeg
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?
On Fri, 8 Dec 2023 at 21:45, Paul M Foster <paulf@quillandmouse.com> wrote:
On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote:Hi, the filename extension is usually irrelevant on Linux, because
On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote: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.
I'm on Debian bookworm, using neomutt for email. Where there is an image to↑↑↑ try jpeg
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?
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 <imagefile>'
command are correctly specified in your desired configuration.
In Unix and Linux there isn't a file extension, that is a microsoft invention.
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 microsoftcc(1) and make(1) would like to have a talk with you.
invention.
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.
cc(1) and make(1) would like to have a talk with you.
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
On 12/8/23 17:31, Greg Wooledge wrote:
On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote:Linux/Unix filenaming specs would like to inform you.
In Unix and Linux there isn't a file extension, that is a microsoftcc(1) and make(1) would like to have a talk with you.
invention.
file specs/naming i Unix and Linux are 355 characters and nothing more.
I am surprised you don't know that
On Fri, Dec 08, 2023 at 05:41:57PM -0500, Pocket wrote:
On 12/8/23 17:31, Greg Wooledge wrote:cc(1) looks at the file extension to decide what kind of content each
On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote:Linux/Unix filenaming specs would like to inform you.
In Unix and Linux there isn't a file extension, that is a microsoftcc(1) and make(1) would like to have a talk with you.
invention.
file specs/naming i Unix and Linux are 355 characters and nothing more.
I am surprised you don't know that
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.
On Fri, Dec 08, 2023 at 04:50:04PM -0600, John Hasler wrote:
Greg writes:What do you consider "the OS" to be, then?
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.
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
rename a jpeg to farts, linux still knows it is a jpeg
In Unix and Linux there isn't a file extension, that is a microsoft invention.
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.
On 2023-12-09, Eric S Fraga <e.fraga@ucl.ac.uk> 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.
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?
<tomas@tuxteam.de> 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.
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↑↑↑ try jpeg
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?
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.
On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote:
<tomas@tuxteam.de> 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/.
On Dec 10, 2023, at 3:05 PM, David Wright <deblis@lionunicorn.co.uk> 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↑↑↑ try jpeg
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?
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.
On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote:
<tomas@tuxteam.de> 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).
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.
On Dec 10, 2023, at 3:05 PM, David Wright <deblis@lionunicorn.co.uk> 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.
On 2023-12-08 17:06:15 -0500, Pocket wrote:
On 12/8/23 16:53, David wrote:More and more applications under Linux, like atril and lynx, care
Hi, the filename extension is usually irrelevant on Linux, becauseIn Unix and Linux there isn't a file extension, that is a microsoft
Linux tools typically
use the standard 'file' command to inspect the content of the
fileinstead of relying on
the filename to indicate content.
invention.
about the file extension.
On 2023-12-10 15:51:02 -0500, Pocket wrote:
On Dec 10, 2023, at 3:05 PM, David Wright<deblis@lionunicorn.co.uk> wrote:A filename extension is a suffix, but a suffix (e.g. as in POSIX)
¹ Re the argument raging in this thread about "extension", theSuffix is the correct term.
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.
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
No it is microsoft non sense
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.
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.
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<deblis@lionunicorn.co.uk> 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.
A filename extension is a suffix, but a suffix (e.g. as in POSIX)I wouldn't want to use "suffix" myself, as it's too general:Suffix is the correct term.
anything stuck on the end is a suffix, but not necessarily
a filename extension. Suffixes are used for other purposes.
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
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.
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) [...]
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.
On 2023-12-11 08:16:30 -0500, Greg Wooledge wrote:
2) When *receiving* email, mutt will use the sender's MIME type labelBut the notion of filename extension is even used in this context too. Quoting the Mutt manual:
to decide how to deal with the attachment.
------------------------------------------------------------
nametemplate=<template>
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.
On 2023-12-11 15:16:57 +0100, tomas@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.
On 2023-12-11 15:16:57 +0100, tomas@tuxteam.de wrote:
On Mon, Dec 11, 2023 at 02:58:01PM +0100, Vincent Lefevre wrote:This is unrelated to the OS. The FAT file system may be used also
I do not care about the "microsoft world", and I doubt that this isThis depends: the FAT file system (which still is the lowest common
required there at the low level (what would be the equivalent of the
Linux kernel) [...]
denominator) actually reserves 8 chars for the file name and three
for the --ahem-- extension. The dot isn't encoded explicitly on-disk.
under Linux (e.g. because this is what some memory sticks have),
and there are the same limitations.
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↑↑↑ try jpeg
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?
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.
On Sun 10 Dec 2023 at 15:51:02 (-0500), Pocket wrote:
So you've said five or six times already. The trouble is that it'sOn Dec 10, 2023, at 3:05 PM, David Wright wrote:Suffix is the correct term.
On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote:
a specially crafted subset of /etc/mailcap with a few additionsOn 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
(like converting webp to a jpeg rather than opening in gimp,
and playing midi files the way I want).
An email would contain headers with the attachment.and↑↑↑ try jpeg
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?
↓
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¹.
A couple of programs in my /etc/mailcap (gpicview and gm) haveI can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and >>>> the files I was looking at had a "jpg" extension.Second, how do I fix this so that mutt uses feh to display images?
But thanks for the tip.
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.
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.
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.
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.
(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.
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 labelBut the notion of filename extension is even used in this context too. Quoting the Mutt manual:
to decide how to deal with the attachment.
------------------------------------------------------------
nametemplate=<template>
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
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"
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
<tomas@tuxteam.de> wrote:
On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote:
<tomas@tuxteam.de> 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.
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:
Similarly, I point it to ~/.config/mutt/mailcap-mutt, which isOn 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,
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↑↑↑ try jpeg
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.
An email would contain headers with the attachment.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?
↓
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¹.
I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), andSecond, how do I fix this so that mutt uses feh to display images?
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:Suffix is the correct term.
anything stuck on the end is a suffix, but not necessarily
a filename extension. Suffixes are used for other purposes.
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?
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
4) File extensions are used by programs on every operating system.
songbird <songbird@anthive.com> wrote:
<tomas@tuxteam.de> wrote:
On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote:
<tomas@tuxteam.de> 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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 31:49:10 |
| Calls: | 6,669 |
| Calls today: | 1 |
| Files: | 12,216 |
| Messages: | 5,338,155 |