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

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

[Paul M Foster]

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.

[David]

On Fri, 8 Dec 2023 at 21:45, Paul M Foster <pa...@quillandmouse.com> 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 <imagefile>'
command are correctly specified in your desired configuration.

[Pocket]

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 <imagefile>'
> command are correctly specified in your desired configuration.
>

--
It's not easy to be me

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

[Pocket]

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

[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
jo...@sugarbit.com
Elmwood, WI USA

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

[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?

[Greg Wooledge]

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.

[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

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

[Pocket]

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

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

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

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

[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

[Curt]

On 2023-12-09, Eric S Fraga <e.f...@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.

I must be stupid or something.

[to...@tuxteam.de]

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

[songbird]

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


songbird

[to...@tuxteam.de]

On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote:
> <to...@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).

Cheers
--
t

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

[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:
> > <to...@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?

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.

[Pocket]

Sent from my iPad

> On Dec 10, 2023, at 3:05 PM, David Wright <deb...@lionunicorn.co.uk> wrote:

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

[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

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

[songbird]

<to...@tuxteam.de> wrote:
> On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote:
>> <to...@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.

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

[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 <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Vincent Lefevre]

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.

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

[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 <deb...@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. 

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/

[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!

[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

[Loris Bennett]

David <bounci...@gmail.com> 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.

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

[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<deb...@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.
> > 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 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=<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.

[to...@tuxteam.de]

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

[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=<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

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

[to...@tuxteam.de]

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

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

[David Wright]

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

[Pocket]

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.

[to...@tuxteam.de]

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

[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=<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

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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.

[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"

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

[debia...@howorth.org.uk]

songbird <song...@anthive.com> wrote:
> <to...@tuxteam.de> wrote:
> > On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote:
> >> <to...@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.

[to...@tuxteam.de]

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

[David Wright]

> > [ … ]

> >
> Where exactly is the variable defined in  the kernel source that a
> file extension is defined
>
> filename is defined as a char "string" of 255 chars, so where is
> extension defined?

In fs/binfmt_misc.c (extracts below are from 5.10, which I happen to
have installed here):

// SPDX-License-Identifier: GPL-2.0-only
/*
* binfmt_misc.c
*
* Copyright (C) 1997 Richard Günther
*
* binfmt_misc detects binaries via a magic or filename extension and invokes
* a specified wrapper. See Documentation/admin-guide/binfmt-misc.rst for more details.
*/

typedef struct {
struct list_head list;
unsigned long flags; /* type, status, etc. */
int offset; /* offset of magic */
int size; /* size of magic/mask */
char *magic; /* magic or filename extension */
char *mask; /* mask, NULL for exact match */
const char *interpreter; /* filename of interpreter */
char *name;
struct dentry *dentry;
struct file *interp_file;
} Node;

/* Parse the 'type' field. */
switch (*p++) {
case 'E':
pr_debug("register: type: E (extension)\n");
e->flags = 1 << Enabled;
break;
case 'M':
pr_debug("register: type: M (magic)\n");
e->flags = (1 << Enabled) | (1 << Magic);
break;
default:
goto einval;
}

/* Handle the 'E' (extension) format. */

/* Skip the 'offset' field. */
p = strchr(p, del);
if (!p)
goto einval;
*p++ = '\0';

/* Parse the 'magic' field. */
e->magic = p;
p = strchr(p, del);
if (!p)
goto einval;
*p++ = '\0';
if (!e->magic[0] || strchr(e->magic, '/'))
goto einval;
pr_debug("register: extension: {%s}\n", e->magic);

if (!test_bit(Magic, &e->flags)) {
sprintf(dp, "extension .%s\n", e->magic);
} else {
dp += sprintf(dp, "offset %i\nmagic ", e->offset);
dp = bin2hex(dp, e->magic, e->size);
if (e->mask) {
dp += sprintf(dp, "\nmask ");
dp = bin2hex(dp, e->mask, e->size);
}
*dp++ = '\n';
*dp = '\0';

}

> Read the books on c programming, a filename is defines as a string of
> chars and in the case of linux 255 chars and the . is not special nor
> is anything following it.  They are all just characters.

Relevance? Books on C? You did write "Read the code, code good."

Here's the actual code:

$ strings /lib/modules/5.10.0-26-amd64/kernel/fs/binfmt_misc.ko | grep -e 'extension' -e 'suffix'
extension .%s
register: extension: {%s}
binfmt_misc: register: type: E (extension)
binfmt_misc: register: extension: {%s}
register: type: E (extension)
$

Also: "I must be blind as I don't see extension anywhere".

> It's not easy to be me

Perhaps we can see why.

Cheers,
David.

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

[songbird]

debia...@howorth.org.uk wrote:
> songbird <song...@anthive.com> wrote:
>> <to...@tuxteam.de> wrote:
>> > On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote:
>> >> <to...@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).

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

[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

[to...@tuxteam.de]

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

[Thomas Schmitt]

Hi,

to...@tuxteam.de wrote:
> 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.

The most extreme example i know is Solaris:

https://docs.oracle.com/cd/E36784_01/html/E36883/fsattr-5.html

fsattr - extended file attributes

Description
Attributes are logically supported as files within the file system.
The file system is therefore augmented with an orthogonal name space of
file attributes. Any file (including attribute files) can have an
arbitrarily deep attribute tree associated with it. Attribute values
are accessed by file descriptors obtained through a special attribute
interface.

So every file can have a second job as directory ... in theory.
In practice, though:

Implementation are [...] permitted to reject operations that are not
supported. For example, the implementation for the UFS file system
allows only regular files as attributes (for example, no
sub-directories) and rejects attempts to place attributes on attributes.


Have a nice day :)

Thomas