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 3 of 3 — ← Prev page 1 2 [3]

#264606

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

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

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

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

#264616

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

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

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

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

No, read the POSIX standard:

  SYNOPSIS
    basename string [suffix]

This is explicitly called suffix.

-- 
Vincent Lefèvre <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]

#264619

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

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

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

#264621

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

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

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

#264623

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

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

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

Cheers
-- 
t

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

#264624

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

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

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

Linux has no such requirement.

-- 
It's not easy to be me

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

#264625

On Sun 10 Dec 2023 at 15:51:02 (-0500), Pocket wrote:
> > On Dec 10, 2023, at 3:05 PM, David Wright wrote:
> > On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote:
> >>> On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote:
> >>> On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:
> >>>> 
> >>>> I'm on Debian bookworm, using neomutt for email. Where there is an image to
> >>>> view, viewing it in neomutt calls up one of the ImageMagick programs. I've set
> >>>> the mailcap_path variable in my neomutt config to point to ~/.mailcap,
> > 
> > Similarly, I point it to ~/.config/mutt/mailcap-mutt, which is
> > a specially crafted subset of /etc/mailcap with a few additions
> > (like converting webp to a jpeg rather than opening in gimp,
> > and playing midi files the way I want).
> > 
> >>>> and
> >>>> set an entry in there for image/jpg to point to /usr/bin/feh. I've even set
> >>>                                  ↑↑↑ try jpeg
> >>> 
> >>>> the "display" alternative to feh with update-alternatives. Still, mutt is
> >>>> calling an imagemagick program to display jpgs.
> >>>> 
> >>>> First, if alternatives doesn't point to the imagemagick program, and the
> >>>> mailcap file doesn't point to it, and there's nothing in the neomutt config
> >>>> pointing to the imagemagick program, then where the heck is it getting that
> >>>> as the program to use to display images?
> > 
> > An email would contain headers with the attachment.
> > 
> >                        ↓
> >  Content-Type: image/jpeg
> >  Content-Disposition: attachment; filename="don.jpg"
> >  Content-Transfer-Encoding: base64
> > 
> > By default, mutt searches six directories for a mailcap file. When
> > found, the line in the mailcap starting with image/jpeg selects the
> > program to run.
> > 
> > If you see an extension in a mailcap field like   nametemplate=%s.jpg
> > that's to show that a filename matching that pattern should be given
> > to a copy of the attachment to satisfy the program that's going to
> > read it. But it's the attachment /content type/ that selects the
> > program, not the extension¹.
> > 
> >>>> Second, how do I fix this so that mutt uses feh to display images?
> >> 
> >> I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and
> >> the files I was looking at had a "jpg" extension.
> >> 
> >> But thanks for the tip.
> > 
> > A couple of programs in my /etc/mailcap (gpicview and gm) have
> > image/jpg lines, duplicating the image/jpeg entries, perhaps
> > as a "catch-all" for malformed emails containing image/jpg.
> > I don't know whether image/jpg is an official legacy type/iana-token.
> > 
> > ¹ Re the argument raging in this thread about "extension", the
> >  term is clearly appropriate, as a glance at /etc/mime.types
> >  demonstrates. The literature is full of the term.
> > 
> >  I wouldn't want to use "suffix" myself, as it's too general:
> >  anything stuck on the end is a suffix, but not necessarily
> >  a filename extension. Suffixes are used for other purposes.
> 
> Suffix is the correct term. 
> File names in Linux are a character string of 255 chars.  Again there are not file extensions in a Linux file name.
> 
> People are conflating the issue.
> 
> Read the code, code good.

So you've said five or six times already. The trouble is that it's
difficult to square this with documentation not only of the OS in
the widest sense, but also the linux kernel itself, which uses the
term extension.

It's often stated, and has been in this thread, that the kernel uses
magic numbers at the start of executables rather than filename
extensions, and while this is true, it's not the only method.

Take a look, for example, at this file (choose your version):

  linux-source-5.10/Documentation/admin-guide/binfmt-misc.rst

  Kernel Support for miscellaneous Binary Formats (binfmt_misc)
  =============================================================

  This Kernel feature allows you to invoke almost (for restrictions
  see below) every program by simply typing its name in the shell.
  This includes for example compiled Java(TM), Python or Emacs programs.

  To achieve this you must tell binfmt_misc which interpreter has to
  be invoked with which binary. Binfmt_misc recognises the binary-type
  by matching some bytes at the beginning of the file with a magic
  byte sequence (masking out specified bits) you have supplied.
  Binfmt_misc can also recognise a filename extension aka ``.com``
  or ``.exe``.

  [ … ]

  ``magic``
  is the byte sequence binfmt_misc is matching for. The magic string
  may contain hex-encoded characters like ``\x0a`` or ``\xA4``. Note
  that you must escape any NUL bytes; parsing halts at the first one.
  In a shell environment you might have to write ``\\x0a`` to prevent
  the shell from eating your ``\``.
  If you chose filename extension matching, this is the extension to be
  recognised (without the ``.``, the ``\x0a`` specials are not allowed).
  Extension matching is case sensitive, and slashes ``/`` are not allowed!

Cheers,
David.

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

#264629

On 12/11/23 09:52, David Wright wrote:
> On Sun 10 Dec 2023 at 15:51:02 (-0500), Pocket wrote:
>>> On Dec 10, 2023, at 3:05 PM, David Wright wrote:
>>> On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote:
>>>>> On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote:
>>>>> On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:
>>>>>> I'm on Debian bookworm, using neomutt for email. Where there is an image to
>>>>>> view, viewing it in neomutt calls up one of the ImageMagick programs. I've set
>>>>>> the mailcap_path variable in my neomutt config to point to ~/.mailcap,
>>> Similarly, I point it to ~/.config/mutt/mailcap-mutt, which is
>>> a specially crafted subset of /etc/mailcap with a few additions
>>> (like converting webp to a jpeg rather than opening in gimp,
>>> and playing midi files the way I want).
>>>
>>>>>> and
>>>>>> set an entry in there for image/jpg to point to /usr/bin/feh. I've even set
>>>>>                                   ↑↑↑ try jpeg
>>>>>
>>>>>> the "display" alternative to feh with update-alternatives. Still, mutt is
>>>>>> calling an imagemagick program to display jpgs.
>>>>>>
>>>>>> First, if alternatives doesn't point to the imagemagick program, and the
>>>>>> mailcap file doesn't point to it, and there's nothing in the neomutt config
>>>>>> pointing to the imagemagick program, then where the heck is it getting that
>>>>>> as the program to use to display images?
>>> An email would contain headers with the attachment.
>>>
>>>                         ↓
>>>   Content-Type: image/jpeg
>>>   Content-Disposition: attachment; filename="don.jpg"
>>>   Content-Transfer-Encoding: base64
>>>
>>> By default, mutt searches six directories for a mailcap file. When
>>> found, the line in the mailcap starting with image/jpeg selects the
>>> program to run.
>>>
>>> If you see an extension in a mailcap field like   nametemplate=%s.jpg
>>> that's to show that a filename matching that pattern should be given
>>> to a copy of the attachment to satisfy the program that's going to
>>> read it. But it's the attachment /content type/ that selects the
>>> program, not the extension¹.
>>>
>>>>>> Second, how do I fix this so that mutt uses feh to display images?
>>>> I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and
>>>> the files I was looking at had a "jpg" extension.
>>>>
>>>> But thanks for the tip.
>>> A couple of programs in my /etc/mailcap (gpicview and gm) have
>>> image/jpg lines, duplicating the image/jpeg entries, perhaps
>>> as a "catch-all" for malformed emails containing image/jpg.
>>> I don't know whether image/jpg is an official legacy type/iana-token.
>>>
>>> ¹ Re the argument raging in this thread about "extension", the
>>>   term is clearly appropriate, as a glance at /etc/mime.types
>>>   demonstrates. The literature is full of the term.
>>>
>>>   I wouldn't want to use "suffix" myself, as it's too general:
>>>   anything stuck on the end is a suffix, but not necessarily
>>>   a filename extension. Suffixes are used for other purposes.
>> Suffix is the correct term.
>> File names in Linux are a character string of 255 chars.  Again there are not file extensions in a Linux file name.
>>
>> People are conflating the issue.
>>
>> Read the code, code good.
> So you've said five or six times already. The trouble is that it's
> difficult to square this with documentation not only of the OS in
> the widest sense, but also the linux kernel itself, which uses the
> term extension.
>
> It's often stated, and has been in this thread, that the kernel uses
> magic numbers at the start of executables rather than filename
> extensions, and while this is true, it's not the only method.
>
> Take a look, for example, at this file (choose your version):
>
>    linux-source-5.10/Documentation/admin-guide/binfmt-misc.rst
>
>    Kernel Support for miscellaneous Binary Formats (binfmt_misc)
>    =============================================================
>
>    This Kernel feature allows you to invoke almost (for restrictions
>    see below) every program by simply typing its name in the shell.
>    This includes for example compiled Java(TM), Python or Emacs programs.
>
>    To achieve this you must tell binfmt_misc which interpreter has to
>    be invoked with which binary. Binfmt_misc recognises the binary-type
>    by matching some bytes at the beginning of the file with a magic
>    byte sequence (masking out specified bits) you have supplied.
>    Binfmt_misc can also recognise a filename extension aka ``.com``
>    or ``.exe``.
>
>    [ … ]
>
>    ``magic``
>    is the byte sequence binfmt_misc is matching for. The magic string
>    may contain hex-encoded characters like ``\x0a`` or ``\xA4``. Note
>    that you must escape any NUL bytes; parsing halts at the first one.
>    In a shell environment you might have to write ``\\x0a`` to prevent
>    the shell from eating your ``\``.
>    If you chose filename extension matching, this is the extension to be
>    recognised (without the ``.``, the ``\x0a`` specials are not allowed).
>    Extension matching is case sensitive, and slashes ``/`` are not allowed!
>
> Cheers,
> David.
>

Where exactly is the variable defined in  the kernel source that a file 
extension is defined

filename is defined as a char "string" of 255 chars, so where is 
extension defined?

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


-- 
It's not easy to be me

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

#264642

On Mon 11 Dec 2023 at 10:03:38 (-0500), Pocket wrote:
> On 12/11/23 09:52, David Wright wrote:
> > On Sun 10 Dec 2023 at 15:51:02 (-0500), Pocket wrote:
> > > > On Dec 10, 2023, at 3:05 PM, David Wright wrote:
> > > > On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote:
> > > > > > On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote:
> > > > > > On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:
> > > > > > > I'm on Debian bookworm, using neomutt for email. Where there is an image to
> > > > > > > view, viewing it in neomutt calls up one of the ImageMagick programs. I've set
> > > > > > > the mailcap_path variable in my neomutt config to point to ~/.mailcap,
> > > > Similarly, I point it to ~/.config/mutt/mailcap-mutt, which is
> > > > a specially crafted subset of /etc/mailcap with a few additions
> > > > (like converting webp to a jpeg rather than opening in gimp,
> > > > and playing midi files the way I want).
> > > > 
> > > > > > > and
> > > > > > > set an entry in there for image/jpg to point to /usr/bin/feh. I've even set
> > > > > >                                   ↑↑↑ try jpeg
> > > > > > 
> > > > > > > the "display" alternative to feh with update-alternatives. Still, mutt is
> > > > > > > calling an imagemagick program to display jpgs.
> > > > > > > 
> > > > > > > First, if alternatives doesn't point to the imagemagick program, and the
> > > > > > > mailcap file doesn't point to it, and there's nothing in the neomutt config
> > > > > > > pointing to the imagemagick program, then where the heck is it getting that
> > > > > > > as the program to use to display images?
> > > > An email would contain headers with the attachment.
> > > > 
> > > >                         ↓
> > > >   Content-Type: image/jpeg
> > > >   Content-Disposition: attachment; filename="don.jpg"
> > > >   Content-Transfer-Encoding: base64
> > > > 
> > > > By default, mutt searches six directories for a mailcap file. When
> > > > found, the line in the mailcap starting with image/jpeg selects the
> > > > program to run.
> > > > 
> > > > If you see an extension in a mailcap field like   nametemplate=%s.jpg
> > > > that's to show that a filename matching that pattern should be given
> > > > to a copy of the attachment to satisfy the program that's going to
> > > > read it. But it's the attachment /content type/ that selects the
> > > > program, not the extension¹.
> > > > 
> > > > > > > Second, how do I fix this so that mutt uses feh to display images?
> > > > > I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and
> > > > > the files I was looking at had a "jpg" extension.
> > > > > 
> > > > > But thanks for the tip.
> > > > A couple of programs in my /etc/mailcap (gpicview and gm) have
> > > > image/jpg lines, duplicating the image/jpeg entries, perhaps
> > > > as a "catch-all" for malformed emails containing image/jpg.
> > > > I don't know whether image/jpg is an official legacy type/iana-token.
> > > > 
> > > > ¹ Re the argument raging in this thread about "extension", the
> > > >   term is clearly appropriate, as a glance at /etc/mime.types
> > > >   demonstrates. The literature is full of the term.
> > > > 
> > > >   I wouldn't want to use "suffix" myself, as it's too general:
> > > >   anything stuck on the end is a suffix, but not necessarily
> > > >   a filename extension. Suffixes are used for other purposes.
> > > Suffix is the correct term.
> > > File names in Linux are a character string of 255 chars.  Again there are not file extensions in a Linux file name.
> > > 
> > > People are conflating the issue.
> > > 
> > > Read the code, code good.
> > So you've said five or six times already. The trouble is that it's
> > difficult to square this with documentation not only of the OS in
> > the widest sense, but also the linux kernel itself, which uses the
> > term extension.
> > 
> > It's often stated, and has been in this thread, that the kernel uses
> > magic numbers at the start of executables rather than filename
> > extensions, and while this is true, it's not the only method.
> > 
> > Take a look, for example, at this file (choose your version):
> > 
> >    linux-source-5.10/Documentation/admin-guide/binfmt-misc.rst
> > [ … ]
> > 
> Where exactly is the variable defined in  the kernel source that a
> file extension is defined
> 
> filename is defined as a char "string" of 255 chars, so where is
> extension defined?

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

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

  typedef struct {
          struct 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.

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

#264630

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

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

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

#264634

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

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

#264637

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

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

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

#264568

> 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

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

#264571

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

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

#264639

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.

[toc] | [prev] | [standalone]

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

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

csiph-web