Re: timeout in shutdown, mutt killed by SIGKILL

[Max Nikulin]

On 04/06/2024 07:29, Vincent Lefevre wrote:

On 2024-05-31 19:05:45 +0700, Max Nikulin wrote:

Do you see an attempt to send SIGTERM to mutt before timeout and SIGKILL?


Unfortunately, there was no information from systemd. Some daemons
log a received SIGTERM, but mutt isn't a daemon.


It is still a part of some systemd.service, try systemd-cgls. If mutt 
does not receive SIGTERM then it has no chance to stop. Perhaps that log 
entry just tells that a signal is sent to the whole cgroup.



What other processes survived first step? Are there something suspicious
before SIGKILL stage?


According to the journalctl output, only mutt survived (the only
process to receive a SIGKILL). And nothing suspicious.


In the previous message you wrote about xdg-document-portal.

Perhaps timeouts are inconsistent for system and user services, so 
user@.service is killed before SIGTERM and SIGKILL stages completed 
withing the systemd user session. However I still expect SIGTERM before 
SIGKILL.


You may start a shell script that logs SIGTERM, but does not exit, to 
test if behavior is similar to your mutt issue.

Re: timeout in shutdown, mutt killed by SIGKILL

[Vincent Lefevre]

On 2024-05-31 19:05:45 +0700, Max Nikulin wrote:
> Do you see an attempt to send SIGTERM to mutt before timeout and SIGKILL?

Unfortunately, there was no information from systemd. Some daemons
log a received SIGTERM, but mutt isn't a daemon.

> What other processes survived first step? Are there something suspicious
> before SIGKILL stage?

According to the journalctl output, only mutt survived (the only
process to receive a SIGKILL). And nothing suspicious.

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

Re: timeout in shutdown, mutt killed by SIGKILL

[Max Nikulin]

On 31/05/2024 15:10, Vincent Lefevre wrote:

https://github.com/flatpak/xdg-desktop-portal/issues/999

I'm wondering whether there could be a same cause.


I can imagine that mutt may start a GUI handler for some attachment and 
that application uses XDG desktop portal. However I would expect that 
mutt just creates a file in /tmp, so it should not prevent mutt from 
quit on SIGTERM. Desktop environment should ensure that the handler runs 
independently of the mutt process (not as a child). Moreover that 
application should be stopped earlier during shutdown.


Do you see an attempt to send SIGTERM to mutt before timeout and 
SIGKILL? What other processes survived first step? Are there something 
suspicious before SIGKILL stage?

Re: timeout in shutdown, mutt killed by SIGKILL

[Vincent Lefevre]

On 2024-05-31 10:10:32 +0200, Vincent Lefevre wrote:
> On 2024-05-31 10:02:57 +0700, Max Nikulin wrote:
> > Do you mean that mutt properly exits unless it receives SIGTERM in the
> > course of shutdown process?
> 
> I think that this was not the first time I did a shutdown while Mutt
> was still running. But this was the first time it did not exit.

I've tried a shutdown with Mutt still running in GNU Screen
a couple of times, and I got no timeout, i.e. Mutt exited as
expected.

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

Re: timeout in shutdown, mutt killed by SIGKILL

[Vincent Lefevre]

On 2024-05-31 10:02:57 +0700, Max Nikulin wrote:
> Do you mean that mutt properly exits unless it receives SIGTERM in the
> course of shutdown process?

I think that this was not the first time I did a shutdown while Mutt
was still running. But this was the first time it did not exit.

> I would try to enable debug log in mutt. There is a chance that
> networking is already disabled (or some other system unit important
> for mutt is already stopped) when systemd tries to kill mutt first
> time.

No, according to the logs, the network was stopped after SIGKILL
was sent to Mutt:

May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. Killing.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 (mutt) 
with signal SIGKILL.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Failed with result 'timeout'.
May 29 01:55:26 qaa systemd[1]: Stopped session-2.scope - Session 2 of User 
vinc17.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Consumed 8h 17min 54.832s CPU 
time.
May 29 01:55:26 qaa systemd[1]: Stopping systemd-logind.service - User Login 
Management...
[...]
May 29 01:55:26 qaa systemd[1]: Stopping NetworkManager.service - Network 
Manager...
May 29 01:55:26 qaa NetworkManager[1238]:   [1716940526.2966] caught 
SIGTERM, shutting down normally.
May 29 01:55:26 qaa NetworkManager[1238]:   [1716940526.2975] dhcp4 
(eth0): canceled DHCP transaction

Note that mutt is not the only case of timeout at shutdown. There's
also

May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: State 
'stop-sigterm' timed out. Killing.
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Killing process 
116031 (xdg-document-po) with signal SIGKILL.
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Killing process 
116037 (fusermount3) with signal SIGKILL.
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Main process 
exited, code=killed, status=9/KILL
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Failed with 
result 'timeout'.

This one is a known issue:

https://github.com/flatpak/xdg-desktop-portal/issues/999

I'm wondering whether there could be a same cause.

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

Re: timeout in shutdown, mutt killed by SIGKILL

[Max Nikulin]

On 30/05/2024 23:19, Vincent Lefevre wrote:


Have you tried to send SIGTERM to mutt?


I didn't. AFAIK, systemd sends a SIGTERM to all the processes of the
session: that's the


Yes, SIGTERM is the default that systemd tries first. There are various 
kill modes, another signal may be configured for a unit, but I would 
leave defaults for user sessions.


Do you mean that mutt properly exits unless it receives SIGTERM in the 
course of shutdown process? I would try to enable debug log in mutt. 
There is a chance that networking is already disabled (or some other 
system unit important for mutt is already stopped) when systemd tries to 
kill mutt first time.

Re: timeout in shutdown, mutt killed by SIGKILL

[Vincent Lefevre]

On 2024-05-30 00:19:30 +0700, Max Nikulin wrote:
> On 29/05/2024 07:44, Vincent Lefevre wrote:
> > But I don't understand why there was a timeout. Does this mean that
> > mutt didn't react to SIGTERM? Any reason?
> 
> Have you tried to send SIGTERM to mutt?

I didn't. AFAIK, systemd sends a SIGTERM to all the processes of the
session: that's the

May 29 01:55:05 qaa systemd[1]: Stopping session-2.scope - Session 2 of User 
vinc17...

but this timed out, apparently due to the mutt process, which was
still running, so that systemd sent a SIGKILL (which succeeded).

May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. Killing.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 (mutt) 
with signal SIGKILL.

> If it ignores this signal or the reaction is some prompt then you
> need to find another way to stop mutt and to configure systemd user
> session to do it on logout (shutdown).

A SIGTERM normally kills mutt. In signal.c, signals are blocked
"while doing critical ops", namely for compressing/decompressing
(which I don't use) and when locking a mailbox (but I don't see
why this would have happened). Otherwise the signal handler just
does that:

static void exit_handler (int sig)
{
  curs_set (1);
  endwin (); /* just to be safe */

  exit_print_string (Caught_Signal_L10N ? Caught_Signal_L10N : "Caught signal 
");
#if SYS_SIGLIST_DECLARED
  exit_print_string (sys_siglist[sig]);
#else
#if (__sun__ && __svr4__)
  exit_print_string (_sys_siglist[sig]);
#else
#if (__alpha && __osf__)
  exit_print_string (__sys_siglist[sig]);
#else
  exit_print_int (sig);
#endif
#endif
#endif
  exit_print_string (Exiting_L10N ? Exiting_L10N : "...  Exiting.\n");
  exit (0);
}

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

Re: timeout in shutdown, mutt killed by SIGKILL

[Vincent Lefevre]

On 2024-05-29 16:13:05 -, Curt wrote:
> On 2024-05-29, Vincent Lefevre  wrote:
> > During the latest shutdown:
> >
> > May 29 01:55:05 qaa systemd[1]: Stopping session-2.scope - Session 2 of 
> > User vinc17...
> > [...]
> > May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. 
> > Killing.
> > May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 
> > (mutt) with signal SIGKILL.
> > May 29 01:55:26 qaa systemd[1]: session-2.scope: Failed with result 
> > 'timeout'.
> > May 29 01:55:26 qaa systemd[1]: Stopped session-2.scope - Session 2 of User 
> > vinc17.
> > May 29 01:55:26 qaa systemd[1]: session-2.scope: Consumed 8h 17min 54.832s 
> > CPU time.
> > May 29 01:55:26 qaa systemd[1]: Stopping systemd-logind.service - User 
> > Login Management...
> > May 29 01:55:26 qaa systemd[1]: Stopping user@1000.service - User Manager 
> > for UID 1000...
> > [...]
> >
> > Note: I had set DefaultTimeoutStopSec=20s because then is normally
> > sufficient.
> >
> > The mutt process was running in GNU Screen. The current mailbox
> > was just a local one. Mutt does no network connections (I do not
> > use IMAP). I general, I quit it before logging out, but this time,
> > it seems that I forgot.
> >
> > But I don't understand why there was a timeout. Does this mean that
> > mutt didn't react to SIGTERM? Any reason?
> >
> 
> sudo journalctl -b-1?

See above. There's nothing else about mutt in the journal.

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

Re: timeout in shutdown, mutt killed by SIGKILL

[Max Nikulin]

On 29/05/2024 07:44, Vincent Lefevre wrote:

But I don't understand why there was a timeout. Does this mean that
mutt didn't react to SIGTERM? Any reason?


Have you tried to send SIGTERM to mutt? If it ignores this signal or the 
reaction is some prompt then you need to find another way to stop mutt 
and to configure systemd user session to do it on logout (shutdown).

Re: timeout in shutdown, mutt killed by SIGKILL

[Curt]

On 2024-05-29, Vincent Lefevre  wrote:
> During the latest shutdown:
>
> May 29 01:55:05 qaa systemd[1]: Stopping session-2.scope - Session 2 of User 
> vinc17...
> [...]
> May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. Killing.
> May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 (mutt) 
> with signal SIGKILL.
> May 29 01:55:26 qaa systemd[1]: session-2.scope: Failed with result 'timeout'.
> May 29 01:55:26 qaa systemd[1]: Stopped session-2.scope - Session 2 of User 
> vinc17.
> May 29 01:55:26 qaa systemd[1]: session-2.scope: Consumed 8h 17min 54.832s 
> CPU time.
> May 29 01:55:26 qaa systemd[1]: Stopping systemd-logind.service - User Login 
> Management...
> May 29 01:55:26 qaa systemd[1]: Stopping user@1000.service - User Manager for 
> UID 1000...
> [...]
>
> Note: I had set DefaultTimeoutStopSec=20s because then is normally
> sufficient.
>
> The mutt process was running in GNU Screen. The current mailbox
> was just a local one. Mutt does no network connections (I do not
> use IMAP). I general, I quit it before logging out, but this time,
> it seems that I forgot.
>
> But I don't understand why there was a timeout. Does this mean that
> mutt didn't react to SIGTERM? Any reason?
>

sudo journalctl -b-1?

timeout in shutdown, mutt killed by SIGKILL

[Vincent Lefevre]

During the latest shutdown:

May 29 01:55:05 qaa systemd[1]: Stopping session-2.scope - Session 2 of User 
vinc17...
[...]
May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. Killing.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 (mutt) 
with signal SIGKILL.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Failed with result 'timeout'.
May 29 01:55:26 qaa systemd[1]: Stopped session-2.scope - Session 2 of User 
vinc17.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Consumed 8h 17min 54.832s CPU 
time.
May 29 01:55:26 qaa systemd[1]: Stopping systemd-logind.service - User Login 
Management...
May 29 01:55:26 qaa systemd[1]: Stopping user@1000.service - User Manager for 
UID 1000...
[...]

Note: I had set DefaultTimeoutStopSec=20s because then is normally
sufficient.

The mutt process was running in GNU Screen. The current mailbox
was just a local one. Mutt does no network connections (I do not
use IMAP). I general, I quit it before logging out, but this time,
it seems that I forgot.

But I don't understand why there was a timeout. Does this mean that
mutt didn't react to SIGTERM? Any reason?

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

Re: URLs in Mutt

[Jonathan Matthew Gresham]

Install urlview

Re: URLs in Mutt

[Nicolas George]

Paul M Foster (12024-01-01):
> Of course, it doesn't fix the retarded way Mutt handles links.

To the better of my knowledge, Mutt does not handle links at all. Please
refrain from calling it retarded.

>   For those
> familiar with Mutt, it allows you to view the file with numbers referring
> to each link. Then you get a screen with just the numbered links. Here's
> the fun part: if the link you want is, say, number 4, when you get to the
> screen with only numbered links, the number 4 link is often some other
> link. You have to push each link around the one you want to the browser
> until you find the one you want. It's a pain.

What you describe does not look like a feature of Mutt but the
combination of two configuration options to use external programs, one
to display HTML as text (as I described elsewhere in the thread) and one
to catch URLs in the text, probably urlview (mentioned by somebody
else).

No need to blame Mutt at all.

Regards,

-- 
  Nicolas George

Re: URLs in Mutt

[Paul M Foster]

On Sun, Dec 31, 2023 at 11:12:12PM -0500, Greg Wooledge wrote:

> On Sun, Dec 31, 2023 at 10:51:25PM -0500, Paul M Foster wrote:
> > Apparently, something was wrapping lines to
> > about 75 characters, and putting an equals sign at the end of every line
> > which had been wrapped.
> 
> This is "quoted-printable" encoding.  You need to use a properly decoded
> version of the file, rather than the raw text.[1]
> 
> > As a solution, I took that email from my mutt mail file and stripped out
> > all the headers and non-HTML content. Then I fed that to my browser.
> 
> If you received a correctly formatted email, it should contain one or more
> parts, each of which is identified by a MIME Content-Type.  Pressing 'v'
> while reading the message takes you to a page which shows you the parts
> in a tree form.
> 
> Use the arrow keys to select the part you want to save (in this case, the
> text/html one), and then save it to a file.  I use "foo.html" usually,
> and just overwrite foo.html every time.
> 
> Have your browser load THAT file.
> 
> [1] The SMTP standard requires all transmitted lines to be 1000 characters
> or less, and to contain only 7-bit ASCII characters.  Therefore, any
> content which doesn't conform to these restrictions has to be encoded.
> The two choices for encoding are quoted-printable, and base64.
> Quoted-printable is nearly human-readable, and is more efficient if
> there are relatively few 8-bit characters or long lines, so it's
> a common choice.  Some MUAs will use q-p even on files that don't
> *strictly* need it, just in case.
> 

This is an excellent reply, and explains the situation entirely. I tried
your method, and it worked. Thanks.

Of course, it doesn't fix the retarded way Mutt handles links. For those
familiar with Mutt, it allows you to view the file with numbers referring
to each link. Then you get a screen with just the numbered links. Here's
the fun part: if the link you want is, say, number 4, when you get to the
screen with only numbered links, the number 4 link is often some other
link. You have to push each link around the one you want to the browser
until you find the one you want. It's a pain.

Paul

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

Re: URLs in Mutt

[fxkl47BF]

On Mon, 1 Jan 2024, Nicolas George wrote:

> This was not a reply to the original mail. You might consider using a
> MUA with proper threading to better understand what is going on.

from the negative nature of your communications
every one understands what's going on

Re: URLs in Mutt

[Nicolas George]

fxkl4...@protonmail.com (12024-01-01):
> actually the question was
> " what is wrapping the lines on my incoming emails, and how do I fix it "
> please try to keep up

This was not a reply to the original mail. You might consider using a
MUA with proper threading to better understand what is going on.

-- 
  Nicolas George

Re: URLs in Mutt

[fxkl47BF]

On Mon, 1 Jan 2024, Nicolas George wrote:

> gene heskett (12024-01-01):
>> Most browsers to well with such as long as the link is surrounded by 
>> the left-right arrows delineate the links contents even if it is wrapped to
>> several lines on your screen.
>
> Please try to keep up with the context of the discussion, we were
> talking about links displayed by “lynx -dump”.

actually the question was
" what is wrapping the lines on my incoming emails, and how do I fix it "
please try to keep up

Re: URLs in Mutt

[Nicolas George]

gene heskett (12024-01-01):
> Most browsers to well with such as long as the link is surrounded by 
> the left-right arrows delineate the links contents even if it is wrapped to
> several lines on your screen.

Please try to keep up with the context of the discussion, we were
talking about links displayed by “lynx -dump”.

Regards,

-- 
  Nicolas George

Re: URLs in Mutt

[gene heskett]

On 1/1/24 11:52, Nicolas George wrote:

Greg Wooledge (12024-01-01):

It's been my experience that the hyperlinks I'm meant to click are so
long that they wrap around the terminal width multiple times.  This
makes copy/pasting them tedious at best, and even then it still
sometimes fails for me.


Surprising. The graphical web browsers I know are actually very tolerant
of spurious newline characters inserted in pasted URLs, and I suspect it
is on purpose. PDFs from magazines might also have wrapped links.

Regards,

Most browsers to well with such as long as the link is surrounded by 
 the left-right arrows delineate the links contents even if it is 
wrapped to several lines on your screen.


Take care all.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: URLs in Mutt

[John Hasler]

Greg Wooledge:
> It's been my experience that the hyperlinks I'm meant to click are so
> long that they wrap around the terminal width multiple times.  This
> makes copy/pasting them tedious at best, and even then it still
> sometimes fails for me.

My wife has the same problem.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: URLs in Mutt

[Nicolas George]

Greg Wooledge (12024-01-01):
> It's been my experience that the hyperlinks I'm meant to click are so
> long that they wrap around the terminal width multiple times.  This
> makes copy/pasting them tedious at best, and even then it still
> sometimes fails for me.

Surprising. The graphical web browsers I know are actually very tolerant
of spurious newline characters inserted in pasted URLs, and I suspect it
is on purpose. PDFs from magazines might also have wrapped links.

Regards,

-- 
  Nicolas George

Re: URLs in Mutt

[Andy Smith]

Hello,

On Mon, Jan 01, 2024 at 09:23:03AM -0500, Greg Wooledge wrote:
> Passing the entire text/html part to an actual web browser has been
> what works best for me.

Me too. I'll do the mailcap thing to visually skim the text/html
part with w3m, but there are so many broken HTML messes that I'm
obliged to read that I also have a hotkey to send that text/html
part to Firefox for proper viewing when necessary.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: URLs in Mutt

[Greg Wooledge]

On Mon, Jan 01, 2024 at 11:42:59AM +0100, Nicolas George wrote:
> Greg Wooledge (12023-12-31):
> > Have your browser load THAT file.
> 
> Or just have this:
> 
> text/html; lynx -force_html -dump %s; copiousoutput
> 
> in your .mailcap file. Possibly along with:
> 
> auto_view text/html
> 
> in the .muttrc.

It's been my experience that the hyperlinks I'm meant to click are so
long that they wrap around the terminal width multiple times.  This
makes copy/pasting them tedious at best, and even then it still
sometimes fails for me.  (Either because I can't actually tell which
one I'm supposed to click, just from reading the lynx-dumped source,
or because there's some Javascript that has to be loaded first?)

Passing the entire text/html part to an actual web browser has been
what works best for me.

On the other hand, if I *don't* want to click anything, the lynx-dumped
source code usually gives me a nice synopsis of what the email is
trying to tell me.  So, it's still worth having, even if I don't
try to copy the URLs out of it manually.

Re: URLs in Mutt

[Nicolas George]

Greg Wooledge (12023-12-31):
> Have your browser load THAT file.

Or just have this:

text/html; lynx -force_html -dump %s; copiousoutput

in your .mailcap file. Possibly along with:

auto_view text/html

in the .muttrc.

Regards,

-- 
  Nicolas George

Re: URLs in Mutt

[Michael Kjörling]

On 31 Dec 2023 22:51 -0500, from pa...@quillandmouse.com (Paul M Foster):
> As a solution, I took that email from my mutt mail file and stripped out
> all the headers and non-HTML content. Then I fed that to my browser. Sorta
> worked. However, the button I was supposed to click didn't work properly.
> It attempted to retrieve a page it couldn't find. Digging deeper, I looked
> into the actual HTML file. Apparently, something was wrapping lines to
> about 75 characters, and putting an equals sign at the end of every line
> which had been wrapped. This apparently interfered with the browser
> correctly interpreting the HTML.

Install the urlview package, and then pass the mail text/html part to
urlview. (I think it'll accept a simple pipe input.) See urlview(1)
for details.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: URLs in Mutt

[Greg Marks]

> Like everyone else, I get emails with links in them which need to be
> clicked to change passwords, verify identity and such. I was a loyal mutt
> user for years, but problems with URLs caused me to eventually change to
> claws-mail. Recently, I tweaked my mutt config, and URLs seemed to work
> better. So I switched back to mutt. All was fine until now. I got a
> critical email with links in it, and it wouldn't work.

In my opinion, being unable to inadvertently click on hyperlinks in
e-mail messages is a major security benefit of Mutt.  If you do want to
open a hyperlink without reading through the HTML source code, finding
the URL, and pasting it into a Web browser, you could include a line
in your .muttrc file such as the following:

   macro attach "\ef" "cat > 
/tmp/mutt_attachment_temporary_file.html ; /usr/bin/firefox 
/tmp/mutt_attachment_temporary_file.html"

Then, when viewing the e-mail in the Mutt pager, type "v" (without the
quotation marks), highlight the main text/html "attachment" (it should
be listed with "no description"), and type "Escape-f" (on my keyboard
"Escape" is the "Alt" key to the left of the space bar), and a copy of
the e-mail will open in Firefox.  You can then click on any hyperlinks
if you're sure they are safe.

Best regards,
Greg Marks


signature.asc
Description: PGP signature

Re: URLs in Mutt

[Greg Wooledge]

On Sun, Dec 31, 2023 at 10:51:25PM -0500, Paul M Foster wrote:
> Apparently, something was wrapping lines to
> about 75 characters, and putting an equals sign at the end of every line
> which had been wrapped.

This is "quoted-printable" encoding.  You need to use a properly decoded
version of the file, rather than the raw text.[1]

> As a solution, I took that email from my mutt mail file and stripped out
> all the headers and non-HTML content. Then I fed that to my browser.

If you received a correctly formatted email, it should contain one or more
parts, each of which is identified by a MIME Content-Type.  Pressing 'v'
while reading the message takes you to a page which shows you the parts
in a tree form.

Use the arrow keys to select the part you want to save (in this case, the
text/html one), and then save it to a file.  I use "foo.html" usually,
and just overwrite foo.html every time.

Have your browser load THAT file.

[1] The SMTP standard requires all transmitted lines to be 1000 characters
or less, and to contain only 7-bit ASCII characters.  Therefore, any
content which doesn't conform to these restrictions has to be encoded.
The two choices for encoding are quoted-printable, and base64.
Quoted-printable is nearly human-readable, and is more efficient if
there are relatively few 8-bit characters or long lines, so it's
a common choice.  Some MUAs will use q-p even on files that don't
*strictly* need it, just in case.

URLs in Mutt

[Paul M Foster]

Folks:

Like everyone else, I get emails with links in them which need to be
clicked to change passwords, verify identity and such. I was a loyal mutt
user for years, but problems with URLs caused me to eventually change to
claws-mail. Recently, I tweaked my mutt config, and URLs seemed to work
better. So I switched back to mutt. All was fine until now. I got a
critical email with links in it, and it wouldn't work. (I know, that's not
a great description.)

As a solution, I took that email from my mutt mail file and stripped out
all the headers and non-HTML content. Then I fed that to my browser. Sorta
worked. However, the button I was supposed to click didn't work properly.
It attempted to retrieve a page it couldn't find. Digging deeper, I looked
into the actual HTML file. Apparently, something was wrapping lines to
about 75 characters, and putting an equals sign at the end of every line
which had been wrapped. This apparently interfered with the browser
correctly interpreting the HTML.

One wrinkle here is that mail is fed to maildrop. In my config file for
this, there is only one line which messes with incoming mail:

xfilter "reformail -f1"

All this does is add a From if an email isn't properly formatted.

So my first question is, what is wrapping the lines on my incoming emails,
and how do I fix it?

Paul

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

On file systems [was: Image handling in mutt]

[tomas]

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

[...]

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

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

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

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

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

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

Interesting times :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Image handling in mutt

[jeremy ardley]

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

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



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


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


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


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

Re: Image handling in mutt

[songbird]

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

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

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


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

  not something i'm worried about for sure.


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

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

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


  songbird

Re: Image handling in mutt

[Jeremy Nicoll]

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

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

Certainly on many OSes, but not all.

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



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

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

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

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

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

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

-- 
Jeremy Nicoll - my opinions are my own.

Re: Image handling in mutt

[David Wright]

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

Re: Image handling in mutt

[tomas]

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

[...]

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

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

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

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

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Image handling in mutt

[David Wright]

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

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

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

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

I use:

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

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

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

I use:

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

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

I prefer to navigate any structure, with:

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

and I find this useful very occasionally:

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

Adding -localhost prevents any external links from working.

Cheers,
David.

Re: Image handling in mutt

[debian-user]

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

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

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

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

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

Re: Image handling in mutt

[Vincent Lefevre]

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

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

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

-- 
Vincent Lefèvre  - Web: <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)

Re: Image handling in mutt

[Stefan Monnier]

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

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

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


Stefan "who likes types"

Re: Image handling in mutt

[Pocket]

On 12/11/23 09:52, David Wright wrote:

On Sun 10 Dec 2023 at 15:51:02 (-0500), Pocket wrote:

On Dec 10, 2023, at 3:05 PM, David Wright wrote:
On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote:

On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote:
On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:

I'm on Debian bookworm, using neomutt for email. Where there is an image to
view, viewing it in neomutt calls up one of the ImageMagick programs. I've set
the mailcap_path variable in my neomutt config to point to ~/.mailcap,

Similarly, I point it to ~/.config/mutt/mailcap-mutt, which is
a specially crafted subset of /etc/mailcap with a few additions
(like converting webp to a jpeg rather than opening in gimp,
and playing midi files the way I want).


and
set an entry in there for image/jpg to point to /usr/bin/feh. I've even set

  ↑↑↑ try jpeg


the "display" alternative to feh with update-alternatives. Still, mutt is
calling an imagemagick program to display jpgs.

First, if alternatives doesn't point to the imagemagick program, and the
mailcap file doesn't point to it, and there's nothing in the neomutt config
pointing to the imagemagick program, then where the heck is it getting that
as the program to use to display images?

An email would contain headers with the attachment.

↓
  Content-Type: image/jpeg
  Content-Disposition: attachment; filename="don.jpg"
  Content-Transfer-Encoding: base64

By default, mutt searches six directories for a mailcap file. When
found, the line in the mailcap starting with image/jpeg selects the
program to run.

If you see an extension in a mailcap field like   nametemplate=%s.jpg
that's to show that a filename matching that pattern should be given
to a copy of the attachment to satisfy the program that's going to
read it. But it's the attachment /content type/ that selects the
program, not the extension¹.


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

I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and
the files I was looking at had a "jpg" extension.

But thanks for the tip.

A couple of programs in my /etc/mailcap (gpicview and gm) have
image/jpg lines, duplicating the image/jpeg entries, perhaps
as a "catch-all" for malformed emails containing image/jpg.
I don't know whether image/jpg is an official legacy type/iana-token.

¹ Re the argument raging in this thread about "extension", the
  term is clearly appropriate, as a glance at /etc/mime.types
  demonstrates. The literature is full of the term.

  I wouldn't want to use "suffix" myself, as it's too general:
  anything stuck on the end is a suffix, but not necessarily
  a filename extension. Suffixes are used for other purposes.

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

People are conflating the issue.

Read the code, code good.

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

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

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

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

   Kernel Support for miscellaneous Binary Formats (binfmt_misc)
   =

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

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

   [ … ]

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

Cheers,
David.



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


f

Re: Image handling in mutt

[tomas]

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

[...]

> > File names in Linux are a character string of 255 chars.  Again there are 
> > not file extensions in a Linux file name.
> > 
> > People are conflating the issue.
> > 
> > Read the code, code good.
> 
> So you've said five or six times already. The trouble is that it's
> difficult to square this with documentation not only of the OS in
> the widest sense, but also the linux kernel itself, which uses the
> term extension.

:-)

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

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

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

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

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Image handling in mutt

[David Wright]

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

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

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

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

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

  Kernel Support for miscellaneous Binary Formats (binfmt_misc)
  =

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

  To achieve this you must tell binfmt_misc which interpreter has to
  be invoked with which binary. Binfmt_

Re: Image handling in mutt

[Pocket]

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

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

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

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

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

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



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

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


Linux has no such requirement.

--
It's not easy to be me

Re: Image handling in mutt

[tomas]

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

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

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Image handling in mutt

[Vincent Lefevre]

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

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

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

Re: Image handling in mutt

[Pocket]

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

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

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

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


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

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


This is due to


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


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

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


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


--
It's not easy to be me

Re: Image handling in mutt

[tomas]

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

[...]

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

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

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

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Image handling in mutt

[Vincent Lefevre]

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

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


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

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


This is due to

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

-- 
Vincent Lefèvre  - Web: <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)

Re: Image handling in mutt

[Vincent Lefevre]

On 2023-12-11 07:32:30 -0500, Pocket wrote:
> 
> On 12/11/23 07:12, Vincent Lefevre wrote:
> > On 2023-12-10 15:51:02 -0500, Pocket wrote:
> > > On Dec 10, 2023, at 3:05 PM, David Wright  
> > > wrote:
> > > > ¹ Re the argument raging in this thread about "extension", the
> > > >   term is clearly appropriate, as a glance at /etc/mime.types
> > > >   demonstrates. The literature is full of the term.
> > > > 
> > > >   I wouldn't want to use "suffix" myself, as it's too general:
> > > >   anything stuck on the end is a suffix, but not necessarily
> > > >   a filename extension. Suffixes are used for other purposes.
> > > Suffix is the correct term.
> > A filename extension is a suffix, but a suffix (e.g. as in POSIX)
> > is not necessarily a filename extension.
> 
> Not in the microsoft world, it is REQUIRED and that is what the OS
> needs to tell what kind of file it is dealing with.  Unix/Linux has
> no resrictions.

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

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

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

No, read the POSIX standard:

  SYNOPSIS
basename string [suffix]

This is explicitly called suffix.

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

Re: Image handling in mutt

[Greg Wooledge]

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

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

The facts are pretty simple:

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

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

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

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

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

Re: Image handling in mutt

[Loris Bennett]

David  writes:

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

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

Cheers,

Loris
  
-- 
This signature is currently under constuction.

Re: Image handling in mutt

[Eric S Fraga]

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

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

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

Re: Image handling in mutt

[Arno Lehmann]

All,

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



I would ask you to continue this discussion elsewhere.

Thanks,

Arno


--
Arno Lehmann

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

Re: Image handling in mutt

[Pocket]

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

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

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

¹ Re the argument raging in this thread about "extension", the
  term is clearly appropriate, as a glance at /etc/mime.types
  demonstrates. The literature is full of the term.

  I wouldn't want to use "suffix" myself, as it's too general:
  anything stuck on the end is a suffix, but not necessarily
  a filename extension. Suffixes are used for other purposes.

Suffix is the correct term.

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


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




For instance:

$ basename foobar bar
foo

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


No bar is part of the filespec




So the notion of "filename extension" is more specific


No it is microsoft non sense

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

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

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

Re: Image handling in mutt

[Pocket]

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

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

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

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

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

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


It is a suffix not extension.

Re: Image handling in mutt

[Vincent Lefevre]

On 2023-12-10 15:51:02 -0500, Pocket wrote:
> On Dec 10, 2023, at 3:05 PM, David Wright  wrote:
> > ¹ Re the argument raging in this thread about "extension", the
> >  term is clearly appropriate, as a glance at /etc/mime.types
> >  demonstrates. The literature is full of the term.
> > 
> >  I wouldn't want to use "suffix" myself, as it's too general:
> >  anything stuck on the end is a suffix, but not necessarily
> >  a filename extension. Suffixes are used for other purposes.
> 
> Suffix is the correct term. 

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

For instance:

$ basename foobar bar
foo

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

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

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

Re: Image handling in mutt

[Vincent Lefevre]

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

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

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

Re: Image handling in mutt

[songbird]

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

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

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

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

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


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

  :)


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

  sure.


  songbird

Re: Image handling in mutt

[Zenaan Harkness]

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

I meant "cleanly _view_ html ..."

Re: Image handling in mutt

[Zenaan Harkness]

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

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

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

Similarly my mailcap entry for pdf files:

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

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

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

Re: Image handling in mutt

[Pocket]

Sent from my iPad

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

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

People are conflating the issue.

Read the code, code good.

> 
> Cheers,
> David.
> 

Re: Image handling in mutt

[David Wright]

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

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

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

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

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

Cheers,
David.

Re: Image handling in mutt

[David Wright]

On Fri 08 Dec 2023 at 16:29:12 (-0500), Paul M Foster wrote:
> On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote:
> > On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:
> > > 
> > > I'm on Debian bookworm, using neomutt for email. Where there is an image 
> > > to
> > > view, viewing it in neomutt calls up one of the ImageMagick programs. 
> > > I've set
> > > the mailcap_path variable in my neomutt config to point to ~/.mailcap,

Similarly, I point it to ~/.config/mutt/mailcap-mutt, which is
a specially crafted subset of /etc/mailcap with a few additions
(like converting webp to a jpeg rather than opening in gimp,
and playing midi files the way I want).

> > > and
> > > set an entry in there for image/jpg to point to /usr/bin/feh. I've even 
> > > set
> >   ↑↑↑ try jpeg
> > 
> > > the "display" alternative to feh with update-alternatives. Still, mutt is
> > > calling an imagemagick program to display jpgs.
> > > 
> > > First, if alternatives doesn't point to the imagemagick program, and the
> > > mailcap file doesn't point to it, and there's nothing in the neomutt 
> > > config
> > > pointing to the imagemagick program, then where the heck is it getting 
> > > that
> > > as the program to use to display images?

An email would contain headers with the attachment.

↓
  Content-Type: image/jpeg
  Content-Disposition: attachment; filename="don.jpg"
  Content-Transfer-Encoding: base64

By default, mutt searches six directories for a mailcap file. When
found, the line in the mailcap starting with image/jpeg selects the
program to run.

If you see an extension in a mailcap field like   nametemplate=%s.jpg
that's to show that a filename matching that pattern should be given
to a copy of the attachment to satisfy the program that's going to
read it. But it's the attachment /content type/ that selects the
program, not the extension¹.

> > > Second, how do I fix this so that mutt uses feh to display images?
> 
> I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and
> the files I was looking at had a "jpg" extension.
> 
> But thanks for the tip.

A couple of programs in my /etc/mailcap (gpicview and gm) have
image/jpg lines, duplicating the image/jpeg entries, perhaps
as a "catch-all" for malformed emails containing image/jpg.
I don't know whether image/jpg is an official legacy type/iana-token.

¹ Re the argument raging in this thread about "extension", the
  term is clearly appropriate, as a glance at /etc/mime.types
  demonstrates. The literature is full of the term.

  I wouldn't want to use "suffix" myself, as it's too general:
  anything stuck on the end is a suffix, but not necessarily
  a filename extension. Suffixes are used for other purposes.

Cheers,
David.

Re: Image handling in mutt

[tomas]

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

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

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

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

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

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

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

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Image handling in mutt

[songbird]

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

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

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

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


  songbird

Re: Image handling in mutt

[tomas]

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

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

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

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

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

Cheers

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


signature.asc
Description: PGP signature

Re: Image handling in mutt

[Curt]

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

They certainly are convenient. 

I must be stupid or something.

Re: Image handling in mutt

[Eric S Fraga]

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

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

Re: Image handling in mutt

[Pocket]

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

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

Greg writes:

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

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

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



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

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

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





--
It's not easy to be me

Re: Image handling in mutt

[Pocket]

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

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

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

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

No it looks for a suffix

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


No "extensions" are required in ms operation systems.

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

look it up





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

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


--
It's not easy to be me

Re: Image handling in mutt

[Greg Wooledge]

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

> No it looks for a suffix

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

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

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

Re: Image handling in mutt

[mick.crane]

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

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

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

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


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


that's a great question
mick

Re: Image handling in mutt

[Pocket]

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

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

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

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

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

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


Linux/Unix filenaming specs would like to inform you.

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

I am surprised you don't know that

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



No it looks for a suffix




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

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



Apache is an application that looks for a file suffix



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


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




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


Non sense

--

It's not easy to be me

Re: Image handling in mutt

[Greg Wooledge]

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

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

Re: Image handling in mutt

[Greg Wooledge]

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

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

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

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

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

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

Re: Image handling in mutt

[Pocket]

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


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

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

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

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


Linux/Unix filenaming specs would like to inform you.

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



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




I am surprised you don't know that



--
It's not easy to be me

Re: Image handling in mutt

[John Hasler]

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

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

Re: Image handling in mutt

[Pocket]

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

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

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

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


Linux/Unix filenaming specs would like to inform you.

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

I am surprised you don't know that


--
It's not easy to be me

Re: Image handling in mutt

[Greg Wooledge]

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

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

Re: Image handling in mutt

[Pocket]

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

On Fri, 8 Dec 2023 at 21:45, Paul M Foster  wrote:

On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote:

On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:

I'm on Debian bookworm, using neomutt for email. Where there is an image to
view, viewing it in neomutt calls up one of the ImageMagick programs. I've set
the mailcap_path variable in my neomutt config to point to ~/.mailcap, and
set an entry in there for image/jpg to point to /usr/bin/feh. I've even set

   ↑↑↑ try jpeg


the "display" alternative to feh with update-alternatives. Still, mutt is
calling an imagemagick program to display jpgs.

First, if alternatives doesn't point to the imagemagick program, and the
mailcap file doesn't point to it, and there's nothing in the neomutt config
pointing to the imagemagick program, then where the heck is it getting that
as the program to use to display images?

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

I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and
the files I was looking at had a "jpg" extension.

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



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


Unix and Linux filespecs are just a bunch of characters

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

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




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


--
It's not easy to be me

Re: Image handling in mutt

[David]

On Fri, 8 Dec 2023 at 21:45, Paul M Foster  wrote:
> On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote:
> > On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:

> > > I'm on Debian bookworm, using neomutt for email. Where there is an image 
> > > to
> > > view, viewing it in neomutt calls up one of the ImageMagick programs. 
> > > I've set
> > > the mailcap_path variable in my neomutt config to point to ~/.mailcap, and
> > > set an entry in there for image/jpg to point to /usr/bin/feh. I've even 
> > > set
> >   ↑↑↑ try jpeg
> >
> > > the "display" alternative to feh with update-alternatives. Still, mutt is
> > > calling an imagemagick program to display jpgs.
> > >
> > > First, if alternatives doesn't point to the imagemagick program, and the
> > > mailcap file doesn't point to it, and there's nothing in the neomutt 
> > > config
> > > pointing to the imagemagick program, then where the heck is it getting 
> > > that
> > > as the program to use to display images?
> > >
> > > Second, how do I fix this so that mutt uses feh to display images?
>
> I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and
> the files I was looking at had a "jpg" extension.

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

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

Re: Image handling in mutt

[Paul M Foster]

On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote:

> On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:
> > 
> > I'm on Debian bookworm, using neomutt for email. Where there is an image to
> > view, viewing it in neomutt calls up one of the ImageMagick programs. I've 
> > set
> > the mailcap_path variable in my neomutt config to point to ~/.mailcap, and
> > set an entry in there for image/jpg to point to /usr/bin/feh. I've even set
>   ↑↑↑ try jpeg
> 
> > the "display" alternative to feh with update-alternatives. Still, mutt is
> > calling an imagemagick program to display jpgs.
> > 
> > First, if alternatives doesn't point to the imagemagick program, and the
> > mailcap file doesn't point to it, and there's nothing in the neomutt config
> > pointing to the imagemagick program, then where the heck is it getting that
> > as the program to use to display images?
> > 
> > Second, how do I fix this so that mutt uses feh to display images?

I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and
the files I was looking at had a "jpg" extension.

But thanks for the tip.

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

Re: Image handling in mutt

[David Wright]

On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:
> 
> I'm on Debian bookworm, using neomutt for email. Where there is an image to
> view, viewing it in neomutt calls up one of the ImageMagick programs. I've set
> the mailcap_path variable in my neomutt config to point to ~/.mailcap, and
> set an entry in there for image/jpg to point to /usr/bin/feh. I've even set
  ↑↑↑ try jpeg

> the "display" alternative to feh with update-alternatives. Still, mutt is
> calling an imagemagick program to display jpgs.
> 
> First, if alternatives doesn't point to the imagemagick program, and the
> mailcap file doesn't point to it, and there's nothing in the neomutt config
> pointing to the imagemagick program, then where the heck is it getting that
> as the program to use to display images?
> 
> Second, how do I fix this so that mutt uses feh to display images?

Cheers,
David.

Image handling in mutt

[Paul M Foster]

Folks:

I'm on Debian bookworm, using neomutt for email. Where there is an image to
view, viewing it in neomutt calls up one of the ImageMagick programs. I've set
the mailcap_path variable in my neomutt config to point to ~/.mailcap, and
set an entry in there for image/jpg to point to /usr/bin/feh. I've even set
the "display" alternative to feh with update-alternatives. Still, mutt is
calling an imagemagick program to display jpgs.

First, if alternatives doesn't point to the imagemagick program, and the
mailcap file doesn't point to it, and there's nothing in the neomutt config
pointing to the imagemagick program, then where the heck is it getting that
as the program to use to display images?

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

Paul

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

Re: [OT] Mutt y Gmail

[Guido Ignacio]

El lun, 9 oct 2023 a las 6:14, alfon () escribió:
>
> > El 28/9/23 a las 20:20, Camaleón escribió:
> >
> > > Desde hace ¿años¹? Gmail ya no permite usar la contraseña que usas
> > > cuando accedes desde el webmail o aplicaciones que admitan sistemas de
> > > autentificación avanzados (OAuth2).
> >
> > parece que desde mayo del 2022 no funciona.
> >
>
> Yo actualmente conecto a gmail dede Mutt usando OAuth, y me funciona
> sin problemas.
>
> http://www.mutt.org/doc/manual/#oauth
>

bueno pude resolverl configurando una clave para aplicacion

Re: [OT] Mutt y Gmail

[alfon]

> El 28/9/23 a las 20:20, Camaleón escribió:
>
> > Desde hace ¿años¹? Gmail ya no permite usar la contraseña que usas
> > cuando accedes desde el webmail o aplicaciones que admitan sistemas de
> > autentificación avanzados (OAuth2).
>
> parece que desde mayo del 2022 no funciona.
>

Yo actualmente conecto a gmail dede Mutt usando OAuth, y me funciona
sin problemas.

http://www.mutt.org/doc/manual/#oauth

Re: [OT] Mutt y Gmail

[Luis Muñoz Fuente]

El 28/9/23 a las 20:20, Camaleón escribió:

> Desde hace ¿años¹? Gmail ya no permite usar la contraseña que usas 
> cuando accedes desde el webmail o aplicaciones que admitan sistemas de 
> autentificación avanzados (OAuth2).

parece que desde mayo del 2022 no funciona.

> 
> Para usar una cuenta IMAP/POP3 al uso, necesitas generar un código 
> para la aplicación desde la configuración del panel web y usar ese 
> código en la aplicaión. El código lo genera Gmail y es bastante 
> inseguro, por cierto, sólo tiene letras en minúsculas :-O.
> 
> De momento, esa opción sigue funcionando (es como lo tengo configurado 
> desde hace ya varios años), pero si no recuerdo mal, para habilitar las 
> contarseñas de aplicación tienes que activar la autentificación de 
> doble factor (2FA) y si quieres acceder también desde el webmail, te 
> manda un SMS cada vez.

He leído la información de google y confirmo todo lo que dice Camaleón

https://support.google.com/accounts/answer/6010255?sjid=5554791994877234454-EU#zippy=%2Cif-less-secure-app-access-is-on-for-your-account%2Cif-less-secure-app-access-is-off-for-your-account


https://support.google.com/accounts/answer/185833?sjid=5554791994877234454-EU

Saludos

Re: [OT] Mutt y Gmail

[Guido Ignacio]

El jue, 28 sept 2023 a las 4:55, Camaleón () escribió:
>
> El 2023-09-28 a las 07:39 +0200, Luis Muñoz Fuente escribió:
>
> No me ha llegado el mensaje original de Guido (no lo tengo ni en /spam
> ni en /todos los correos de Gmail), respondo a través del correo de
> Luis.
>
> > El 28/9/23 a las 5:18, Guido Ignacio escribió:
> > > Antes recuerdo era configurar imap y smtp en .muttrc y salia andando.
> >
> > Hola:
> > Hace tiempo que no consulto ninguna cuenta de gmail con mutt y la
> > configuración que tenía en .muttrc ya no me sirve:
> >
> > set imap_user = "USUARIO"; set imap_pass = "CLAVE"; set folder =
> > "imaps://imap.gmail.com:993";set smtp_url =
> > "smtp://USUARIO:CLAVE?@smtp.gmail.com:587"
> >
> > Y tengo permitido el acceso de terceros a la cuenta.
>
> Uso Mutt habitualmente para las listas de correo (ahora mismo respondo
> desde Mutt), pero la configuración básica que te ha indicado Luis
> debería ser suficiente para que funcione (al menos para que conecte con
> Gmail).
>
> Añado que también suele ser útil iniciar Mutt en modo de depuración
> para ver por dónde pueden ir los tiros (mutt -d 2).
>
> Saludos,
>
> --
> Camaleón
>

¿Y utilizas credenciales de google o contraseña de aplicación?

Re: [OT] Mutt y Gmail

[fernando sainz]

El jue, 28 sept 2023 a las 7:40, Luis Muñoz Fuente (<
luis.munoz@juntadeandalucia.es>) escribió:

>
> El 28/9/23 a las 5:18, Guido Ignacio escribió:
> > Antes recuerdo era configurar imap y smtp en .muttrc y salia andando.
>
> Hola:
> Hace tiempo que no consulto ninguna cuenta de gmail con mutt y la
> configuración que tenía en .muttrc ya no me sirve:
>
> set imap_user = "USUARIO"; set imap_pass = "CLAVE"; set folder =
> "imaps://imap.gmail.com:993";set smtp_url =
> "smtp://USUARIO:CLAVE?@smtp.gmail.com:587"
>
> Y tengo permitido el acceso de terceros a la cuenta.
> Saludos
>
>

 Google se volvió muy preocupado por la seguridad y ahora a veces las cosas
se complican.
Es posible que para activar la posibilidad de usar "claves de aplicación"
ajenas a sus productos tengas que activar el tema ese de la doble
autenticación y luego ya te permita definir lo que creo que llamaba "claves
de aplicación" que permiten el acceso a otras aplicaciones con una clave
especial para mutt.
Busca un poco y seguro que lo encuentras.

https://support.google.com/accounts/answer/185833?hl=es

Saludos.

Re: [OT] Mutt y Gmail

[Camaleón]

El 2023-09-28 a las 07:39 +0200, Luis Muñoz Fuente escribió:

No me ha llegado el mensaje original de Guido (no lo tengo ni en /spam 
ni en /todos los correos de Gmail), respondo a través del correo de 
Luis.
 
> El 28/9/23 a las 5:18, Guido Ignacio escribió:
> > Antes recuerdo era configurar imap y smtp en .muttrc y salia andando.
> 
> Hola:
> Hace tiempo que no consulto ninguna cuenta de gmail con mutt y la
> configuración que tenía en .muttrc ya no me sirve:
> 
> set imap_user = "USUARIO"; set imap_pass = "CLAVE"; set folder =
> "imaps://imap.gmail.com:993";set smtp_url =
> "smtp://USUARIO:CLAVE?@smtp.gmail.com:587"
> 
> Y tengo permitido el acceso de terceros a la cuenta.

Uso Mutt habitualmente para las listas de correo (ahora mismo respondo 
desde Mutt), pero la configuración básica que te ha indicado Luis 
debería ser suficiente para que funcione (al menos para que conecte con
Gmail).

Añado que también suele ser útil iniciar Mutt en modo de depuración 
para ver por dónde pueden ir los tiros (mutt -d 2).

Saludos,

-- 
Camaleón 

Re: [OT] Mutt y Gmail

[Luis Muñoz Fuente]

El 28/9/23 a las 5:18, Guido Ignacio escribió:
> Antes recuerdo era configurar imap y smtp en .muttrc y salia andando.

Hola:
Hace tiempo que no consulto ninguna cuenta de gmail con mutt y la
configuración que tenía en .muttrc ya no me sirve:

set imap_user = "USUARIO"; set imap_pass = "CLAVE"; set folder =
"imaps://imap.gmail.com:993";set smtp_url =
"smtp://USUARIO:CLAVE?@smtp.gmail.com:587"

Y tengo permitido el acceso de terceros a la cuenta.
Saludos

[OT] Mutt y Gmail

[Guido Ignacio]

Hola! les consulto, alguien está usando totalmente funcional mutt con gmail?

He querido volver a usar mutt pero no doy con la configuración
correcta de todas las que encuentro por ahi.

Antes recuerdo era configurar imap y smtp en .muttrc y salia andando.

Si alguien me da una mano,genial!

Gracias!

Re: mail --> mutt

[Alex Muntada]

Hola, Ernest:

> El fet que l'MTA tingui una cua interna de missatges (a
> diferència d'un MUA), no veig que sigui gaire rellevant,
> ja que l'únic que fa l'MTA local és connectar-se a l'MTA
> extern (és l'escenari que estavem discutint).

Quan aquesta connexió al MTA extern falla, et pot interessar
tenir una cua local per no perdre missatges. Potser en el cas
d'una persona no perquè el MUA ja li dirà que ha fallat la
connexió, és clar. Però si hi ha d'altres casos en què conviuen
una persona i algun procés que envia correu al MTA extern,
aquí podria tenir sentit un MTA local amb una cua perquè, si
falla la connexió, el procés no podrà enviar el correu (què se'n
farà depèn del MUA del procés, és clar).

> Per altra banda, quin MTA extern penseu utilitzar?

Qualsevol que ja et doni servei al MUA o un de corporatiu,
si el correu s'envia des de dins d'una organització que ho
permet.

Per exemple, si el meu correu està a Gandi i m'hi connecto amb
Mutt normalment via SMTP, podria configurar el meu MTA local per
enviar el correu sortint via Gandi utilitzant les mateixes
credencials d'usuari. Jo no tinc configurat el meu MTA local així
perquè no tinc processos que enviïn correus cap a fora dels meus
equips de treball, però hi ha gent que ho fa i així pot utilitzar
qualsevol MUA local per enviar correu.

A la xarxa interna de la UPC tenim un MTA al que podem enviar
missatges que vagin a qualsevol lloc sense autenticar-nos. Així,
qualsevol servidor el pot utilitzar per enviar correu fàcilment.

Espero haver-me explicat millor.

Salut,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Re: mail --> mutt

[Alex Muntada]

Hola, Eloi:

> Ho dic perquè hi ha una opció més potent fent servir sieve

Jo només he vist Sieve en servidors IMAP (cyrus, dovecot, etc.) i
no sabia que també es podia utilitzar en local (gràcies!).

Altres eines per a filtrar que he conec són procmail i mailfilter.

Salut,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Re: mail --> mutt

[Ernest Adrogué]

2023-07- 8, 07:20 (+0200); Xavier Drudis Ferran escriu:
> El Fri, Jul 07, 2023 at 01:39:30PM +, Ernest Adrogué deia:
> > 2023-07- 7, 09:59 (+0200); Narcis Garcia escriu:
> > > Em sembla que l'Alex es referia a aquest recorregut per a «smarthost»:
> > > MUA (Mutt) -> MTA local -> MTA públic
> > > 
> > > Amb això, el servidor públic de correu-e és el què ha d'acreditar-se a
> > > Internet com a fiable per als filtres anti-brossa.
> > 
> > En aquest cas ho trobo una complicació innecessària.
> > 
> > L'MUA es pot connectar directament a l'MTA públic, sense necessitat de
> > passar per l'MTA local, que no aporta res, o pràcticament res.
> > 
> 
> Si ho tens clar ja ho tens clar.
> 
> Però un MTA local pot aportar cues (esperar a poder enviar) i
> lliurament a adreces locals que no existeixen al MTA públic.
> 
> Segur que li pòts buscar més coses, però aquestes són les principals
> que em passen pel cap. Crec que l'Alex ja anava per aquí.

En el meu missatge recomano utilitzar un MTA local per permetre
l'enviament de correu a adreces locals.  Per tant, no estic recomanant
no utilizar MTAs locals, en general.  Només recomano no utilitzar-los
per enviar correu a adreces externes (a no ser que siguis una
organització que tingui la infrastructura necessària).

El fet que l'MTA tingui una cua interna de missatges (a diferència d'un
MUA), no veig que sigui gaire rellevant, ja que l'únic que fa l'MTA
local és connectar-se a l'MTA extern (és l'escenari que estavem
discutint).  En aquest escenari, qui gestiona la cua de missatges és
l'MTA extern.

Per altra banda, quin MTA extern penseu utilitzar?  No hi ha gaires
alternatives.  Gmail?  Penseu que és bona idea forçar tot el correu que
s'origina localment a través de l'MTA de Gmail?  Jo crec que no, jo crec
que és una idea terrible.  La decisió de quin MTA extern utilitzar és
millor deixar-la en mans de l'usuari.

Un altre problema, si no recordo malament, és que alguns MUAs afegeixen
una advertència quan l'adreça que s'autentica a l'MTA extern no
coincideix amb l'adreça del destinatari.  El destinatari veu dos
remitents, i un text que diu que el missatge l'envia un remitent per
compte de l'altre.  Pot generar confusió, i a més revela informació que
potser és millor no revelar.


> Si això no et convé, o no et compensa, no tens perquè tenir MTA local,
> com menys coses millor, només és una idea que t'han donat.

Exacte, només és una idea, i com qualsevol idea té arguments a favor i
arguments en contra, i això és el que estem debatent.


Salutacions.

Re: mail --> mutt

[Xavier Drudis Ferran]

El Fri, Jul 07, 2023 at 01:39:30PM +, Ernest Adrogué deia:
> 2023-07- 7, 09:59 (+0200); Narcis Garcia escriu:
> > Em sembla que l'Alex es referia a aquest recorregut per a «smarthost»:
> > MUA (Mutt) -> MTA local -> MTA públic
> > 
> > Amb això, el servidor públic de correu-e és el què ha d'acreditar-se a
> > Internet com a fiable per als filtres anti-brossa.
> 
> En aquest cas ho trobo una complicació innecessària.
> 
> L'MUA es pot connectar directament a l'MTA públic, sense necessitat de
> passar per l'MTA local, que no aporta res, o pràcticament res.
> 

Si ho tens clar ja ho tens clar.

Però un MTA local pot aportar cues (esperar a poder enviar) i
lliurament a adreces locals que no existeixen al MTA públic.

Segur que li pòts buscar més coses, però aquestes són les principals
que em passen pel cap. Crec que l'Alex ja anava per aquí.

Si això no et convé, o no et compensa, no tens perquè tenir MTA local,
com menys coses millor, només és una idea que t'han donat.

Re: mail --> mutt

[Ernest Adrogué]

2023-07- 7, 09:59 (+0200); Narcis Garcia escriu:
> Em sembla que l'Alex es referia a aquest recorregut per a «smarthost»:
> MUA (Mutt) -> MTA local -> MTA públic
> 
> Amb això, el servidor públic de correu-e és el què ha d'acreditar-se a
> Internet com a fiable per als filtres anti-brossa.

En aquest cas ho trobo una complicació innecessària.

L'MUA es pot connectar directament a l'MTA públic, sense necessitat de
passar per l'MTA local, que no aporta res, o pràcticament res.

Salutacions.

Re: mail --> mutt

[Narcis Garcia]

El 7/7/23 a les 9:39, Ernest Adrogué ha escrit:

2023-07- 5, 21:51 (+0200); Alex Muntada escriu:

Hola, Ernest:


No és recomanable utilitzar postfix per enviar correu a
internet. El més pràctic és utilitzar el postfix (o un altre
MTA) per enviar correu localment al mateix ordinador, i si els
usuaris volen enviar correu a internet que utilitzin un client
de correu (com el mutt) que permeti enviar correu a través d'un
servidor de correu remot (com Gmail).


M'havia quedant pendent de respondre aquest tema: això depèn de
les necessitats particulars. En concret, és molt habitual tenir
un MTA configurat amb un smarthost per processar tot el correu
que no és local, sobretot als servidors.

Per exemple, si enlloc de deixar en local els missatges que
t'envia el cron, els vols rebre a una altra bústia remota, el
MTA local ho pot fer perfectament via smarthost.

Tenir un MTA local, a més a més, pot ser útil per encuar els
missatges de sortida quan no tens connexió a internet. Potser
alguns MUA ho reintentaran, però d'altres no (per exemple, Mutt
ha començat a reintentar connexions des de fa poc) i el MTA local
fa de coixí.


Tinc entès que les mesures anti-spam fan que aquest sistema no sigui
viable a la pràctica.  Per exemple: l'MTA local pot enviar correu sense
problemes quan el domini de l'adreça del remitent no coincideix amb el
domini de l'MTA, o en aquests casos l'MTA del destinatari tendeix a
rebutjar el correu?

Salutacions.



Em sembla que l'Alex es referia a aquest recorregut per a «smarthost»:
MUA (Mutt) -> MTA local -> MTA públic

Amb això, el servidor públic de correu-e és el què ha d'acreditar-se a 
Internet com a fiable per als filtres anti-brossa.


--

Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't 
masked enough at this mail public archive. Public archive administrator 
should fix this against automated addresses collectors.

Re: mail --> mutt

[Ernest Adrogué]

2023-07- 5, 21:51 (+0200); Alex Muntada escriu:
> Hola, Ernest:
> 
> > No és recomanable utilitzar postfix per enviar correu a
> > internet. El més pràctic és utilitzar el postfix (o un altre
> > MTA) per enviar correu localment al mateix ordinador, i si els
> > usuaris volen enviar correu a internet que utilitzin un client
> > de correu (com el mutt) que permeti enviar correu a través d'un
> > servidor de correu remot (com Gmail).
> 
> M'havia quedant pendent de respondre aquest tema: això depèn de
> les necessitats particulars. En concret, és molt habitual tenir
> un MTA configurat amb un smarthost per processar tot el correu
> que no és local, sobretot als servidors.
> 
> Per exemple, si enlloc de deixar en local els missatges que
> t'envia el cron, els vols rebre a una altra bústia remota, el
> MTA local ho pot fer perfectament via smarthost.
> 
> Tenir un MTA local, a més a més, pot ser útil per encuar els
> missatges de sortida quan no tens connexió a internet. Potser
> alguns MUA ho reintentaran, però d'altres no (per exemple, Mutt
> ha començat a reintentar connexions des de fa poc) i el MTA local
> fa de coixí.

Tinc entès que les mesures anti-spam fan que aquest sistema no sigui
viable a la pràctica.  Per exemple: l'MTA local pot enviar correu sense
problemes quan el domini de l'adreça del remitent no coincideix amb el
domini de l'MTA, o en aquests casos l'MTA del destinatari tendeix a
rebutjar el correu?

Salutacions.

Re: mail --> mutt

[Eloi]

El 16/6/23 a les 21:26, Jordi ha escrit:

[...]


2023-06-15, 10:29 (+0200); Jordi escriu:

Ja fa un temps vaig voler configurar postfix i alguna altra cosa
i no
me'n vaig sortir, el que tinc ara son aplicacions que envien
notificacions o redirigeixo la sortida a mail o a mutt segons si
vull
local o remotament.


Entenc que filtres el correu segons qui el genera. Ho dic perquè hi ha 
una opció més potent fent servir sieve (el que uso jo està al paquet del 
GNU mailutils). En la configuració que tinc a la feina (la consulto quan 
hi arribi, ho vaig muntar fa temps) redirigeixo correus locals del cron 
d'un mateix usuari segons criteris tal com l'assumpte o una paraula clau 
del cos a diferents bústies locals, de tal forma que em resulta molt més 
fàcil anar a cercar quelcom si ho necessito, puix en alguns casos tinc 
correus cada cinc minuts.


En el meu cas faig redireccions a bústies locals, però el llenguatge de 
sieve permet moltes més possibilitats, entre elles el reenviament de 
correus. Clar que, per això, necessites que el teu agent de correu local 
pugui fer entrega remota, el que ens porta a la segona part.



Exacte, algunes notificacions amb mail i altres més importants amb mutt
perquè arribin a l'ordinador de casa via el servidor de correu que
utilitzo (runbox). És així per evitar que al final, i com ha passat
alguna vegada, per algun error s'han enviat massa notificacions i al
final van a la carpeta spam o bé em passo de quota.

La meva primera opció era enviar totes les notificacions directament a
l'ordinador de casa, però ho vaig descartar perquè no tenia forma de
veure si era prou segur, i tampoc vull deixar un sucós servidor smtp
mal configurat.


Una cosa que podries provar és si l'enviament directe de correu des del 
servidor que el genera a la teva bústia funciona. Això depèn de bastants 
factors i pot ser que avui funcioni i demà ja no: és una opció que no 
recomano si els correus són importants i/o el muntatge ha de durar en el 
temps. Ajuda bastant que el servidor que l'enviï tingui IP fixa.


Alternativament, també si el remitent té IP fixa, podries arribar a 
configurar un SMTP d'entrada local a destinació però limitant-lo, tant a 
configuració del propi MTA (exim4 ho permet) com a nivell de tallafoc 
per acceptar connexions únicament des de la direcció IP que t'interessa, 
i en cap cas permetent el relay de correu.

Re: mail --> mutt

[Alex Muntada]

Hola, Ernest:

> No és recomanable utilitzar postfix per enviar correu a
> internet. El més pràctic és utilitzar el postfix (o un altre
> MTA) per enviar correu localment al mateix ordinador, i si els
> usuaris volen enviar correu a internet que utilitzin un client
> de correu (com el mutt) que permeti enviar correu a través d'un
> servidor de correu remot (com Gmail).

M'havia quedant pendent de respondre aquest tema: això depèn de
les necessitats particulars. En concret, és molt habitual tenir
un MTA configurat amb un smarthost per processar tot el correu
que no és local, sobretot als servidors.

Per exemple, si enlloc de deixar en local els missatges que
t'envia el cron, els vols rebre a una altra bústia remota, el
MTA local ho pot fer perfectament via smarthost.

Tenir un MTA local, a més a més, pot ser útil per encuar els
missatges de sortida quan no tens connexió a internet. Potser
alguns MUA ho reintentaran, però d'altres no (per exemple, Mutt
ha començat a reintentar connexions des de fa poc) i el MTA local
fa de coixí.

Ara bé, em sembla intuir que la teva recomanació va en la línia
de no tenir un MTA públic, és a dir, tenir un servidor propi de
correu per enviar i rebre missatges de tot Internet. Si és això,
totalment d'acord amb tu. Si algú està interessat en les raons,
podem obrir un fil a part.

Salut!
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature