Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #264430 > unrolled thread

Image handling in mutt

Back to article view | Back to linux.debian.user

Contents

  Image handling in mutt Paul M Foster <paulf@quillandmouse.com> - 2023-12-08 18:00 +0100
    Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-08 18:10 +0100
      Re: Image handling in mutt Paul M Foster <paulf@quillandmouse.com> - 2023-12-08 22:50 +0100
        Re: Image handling in mutt David <bouncingcats@gmail.com> - 2023-12-08 23:00 +0100
          Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-08 23:10 +0100
            Re: Image handling in mutt Greg Wooledge <greg@wooledge.org> - 2023-12-08 23:40 +0100
              Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-08 23:50 +0100
                Re: Image handling in mutt Greg Wooledge <greg@wooledge.org> - 2023-12-09 00:00 +0100
                  Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-09 00:10 +0100
                    Re: Image handling in mutt Greg Wooledge <greg@wooledge.org> - 2023-12-09 00:20 +0100
                      Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-09 00:30 +0100
                Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-09 00:00 +0100
              Re: Image handling in mutt John Hasler <john@sugarbit.com> - 2023-12-09 00:00 +0100
                Re: Image handling in mutt Greg Wooledge <greg@wooledge.org> - 2023-12-09 00:00 +0100
                  Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-09 00:30 +0100
            Re: Image handling in mutt Eric S Fraga <e.fraga@ucl.ac.uk> - 2023-12-09 09:50 +0100
              Re: Image handling in mutt Curt <curty@free.fr> - 2023-12-10 17:20 +0100
                Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-10 17:30 +0100
                  Re: Image handling in mutt songbird <songbird@anthive.com> - 2023-12-10 19:40 +0100
                    Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-10 19:50 +0100
                      Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-10 21:20 +0100
                      Re: Image handling in mutt songbird <songbird@anthive.com> - 2023-12-11 02:30 +0100
                        Re: Image handling in mutt debian-user@howorth.org.uk - 2023-12-11 16:30 +0100
                          Re: Image handling in mutt songbird <songbird@anthive.com> - 2023-12-11 21:20 +0100
            Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 12:40 +0100
              Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-11 13:30 +0100
          Re: Image handling in mutt "Loris Bennett" <loris.bennett@fu-berlin.de> - 2023-12-11 14:10 +0100
        Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-10 21:10 +0100
          Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-10 22:00 +0100
            Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 13:20 +0100
              Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-11 13:40 +0100
                Re: Image handling in mutt Arno Lehmann <al@its-lehmann.de> - 2023-12-11 13:50 +0100
                  Re: Image handling in mutt Greg Wooledge <greg@wooledge.org> - 2023-12-11 14:20 +0100
                    Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 15:10 +0100
                      Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-11 15:40 +0100
                        Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 16:20 +0100
                    Re: Image handling in mutt "Jeremy Nicoll" <jn.ml.dbi.73@letterboxes.org> - 2023-12-11 19:00 +0100
                      Re: Image handling in mutt jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-11 23:10 +0100
                        On file systems [was: Image handling in mutt] <tomas@tuxteam.de> - 2023-12-12 06:40 +0100
                          Re: On file systems "Thomas Schmitt" <scdbackup@gmx.net> - 2023-12-12 11:50 +0100
                Re: Image handling in mutt Eric S Fraga <e.fraga@ucl.ac.uk> - 2023-12-11 13:50 +0100
                Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 15:00 +0100
                  Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-11 15:20 +0100
                    Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 15:40 +0100
                      Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-11 15:50 +0100
                      Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-11 15:50 +0100
            Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-11 16:00 +0100
              Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-11 16:10 +0100
                Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-11 17:10 +0100
              Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-11 16:10 +0100
                Re: Image handling in mutt Stefan Monnier <monnier@iro.umontreal.ca> - 2023-12-11 16:20 +0100
                  Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-11 16:30 +0100
    Re: Image handling in mutt Zenaan Harkness <zenaan@gmail.com> - 2023-12-11 00:10 +0100
      Re: Image handling in mutt Zenaan Harkness <zenaan@gmail.com> - 2023-12-11 01:20 +0100
      Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-11 16:30 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#264556

On Sun 10 Dec 2023 at 19:48:29 (+0100), tomas@tuxteam.de wrote:
> 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?

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.

[toc] | [prev] | [next] | [standalone]

#264574

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


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

[toc] | [prev] | [next] | [standalone]

#264638

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.

[toc] | [prev] | [next] | [standalone]

#264654

debian-user@howorth.org.uk wrote:
> 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).

  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

[toc] | [prev] | [next] | [standalone]

#264597

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 <vincent@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)

[toc] | [prev] | [next] | [standalone]

#264601

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.

[toc] | [prev] | [next] | [standalone]

#264608

David <bouncingcats@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.

[toc] | [prev] | [next] | [standalone]

#264555

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.

[toc] | [prev] | [next] | [standalone]

#264560

Sent from my iPad

> 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
>>>> set an entry in there for image/jpg to point to /usr/bin/feh. I've even set
>>>                                  ↑↑↑ try jpeg
>>> 
>>>> the "display" alternative to feh with update-alternatives. Still, mutt is
>>>> calling an imagemagick program to display jpgs.
>>>> 
>>>> First, if alternatives doesn't point to the imagemagick program, and the
>>>> mailcap file doesn't point to it, and there's nothing in the neomutt config
>>>> pointing to the imagemagick program, then where the heck is it getting that
>>>> as the program to use to display images?
> 
> An email would contain headers with the attachment.
> 
>                        ↓
>  Content-Type: image/jpeg
>  Content-Disposition: attachment; filename="don.jpg"
>  Content-Transfer-Encoding: base64
> 
> By default, mutt searches six directories for a mailcap file. When
> found, the line in the mailcap starting with image/jpeg selects the
> program to run.
> 
> If you see an extension in a mailcap field like   nametemplate=%s.jpg
> that's to show that a filename matching that pattern should be given
> to a copy of the attachment to satisfy the program that's going to
> read it. But it's the attachment /content type/ that selects the
> program, not the extension¹.
> 
>>>> Second, how do I fix this so that mutt uses feh to display images?
>> 
>> I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and
>> the files I was looking at had a "jpg" extension.
>> 
>> But thanks for the tip.
> 
> A couple of programs in my /etc/mailcap (gpicview and gm) have
> image/jpg lines, duplicating the image/jpeg entries, perhaps
> as a "catch-all" for malformed emails containing image/jpg.
> I don't know whether image/jpg is an official legacy type/iana-token.
> 
> ¹ Re the argument raging in this thread about "extension", the
>  term is clearly appropriate, as a glance at /etc/mime.types
>  demonstrates. The literature is full of the term.
> 
>  I wouldn't want to use "suffix" myself, as it's too general:
>  anything stuck on the end is a suffix, but not necessarily
>  a filename extension. Suffixes are used for other purposes.

Suffix is the correct term. 
File names in Linux are a character string of 255 chars.  Again there are not file extensions in a Linux file name.

People are conflating the issue.

Read the code, code good.

> 
> Cheers,
> David.
> 

[toc] | [prev] | [next] | [standalone]

#264600

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.
> > 
> >  I wouldn't want to use "suffix" myself, as it's too general:
> >  anything stuck on the end is a suffix, but not necessarily
> >  a filename extension. Suffixes are used for other purposes.
> 
> Suffix is the correct term. 

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

For instance:

$ basename foobar bar
foo

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

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

-- 
Vincent Lefèvre <vincent@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)

[toc] | [prev] | [next] | [standalone]

#264602

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#264604

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

[toc] | [prev] | [next] | [standalone]

#264611

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.

[toc] | [prev] | [next] | [standalone]

#264618

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.

-- 
Vincent Lefèvre <vincent@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)

[toc] | [prev] | [next] | [standalone]

#264622

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


-- 
It's not easy to be me

[toc] | [prev] | [next] | [standalone]

#264635

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
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >     determine how to deal with input files.
> 
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:struct filename {
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:static_assert(offsetof(struct filename, iname) % sizeof(long) == 0);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct file *file_open_name(struct filename *, int, umode_t);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct filename *getname_flags(const char __user *, int, int *);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct filename *getname_uflags(const char __user *, int);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct filename *getname(const char __user *);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct filename *getname_kernel(const char *);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern void putname(struct filename *name);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs_context.h:		struct filename	*name;
> 
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_chdir(const char *filename);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_chroot(const char *filename);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_chown(const char *filename, uid_t user, gid_t group, int flags);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_chmod(const char *filename, umode_t mode);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_eaccess(const char *filename);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_stat(const char *filename, struct kstat *stat, int flags);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_mknod(const char *filename, umode_t mode, unsigned int dev);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_utimes(char *filename, struct timespec64 *ts);
> 
> I must be blind as I don't see extension anywhere

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

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

-- 
Vincent Lefèvre <vincent@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)

[toc] | [prev] | [next] | [standalone]

#264649

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.

[toc] | [prev] | [next] | [standalone]

#264657

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

[toc] | [prev] | [next] | [standalone]

#264661 — On file systems [was: Image handling in mutt]

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#264663 — Re: On file systems

Hi,

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web