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

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

metamail now misbehaving

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

Contents

  metamail now misbehaving Steve Kleene <skdeb@syrano.acb.uc.edu> - 2017-07-09 20:30 +0200
    Re: metamail now misbehaving David Wright <deblis@lionunicorn.co.uk> - 2017-07-09 23:00 +0200
    Re: metamail now misbehaving Ángel <debian-user@debian.16bits.net> - 2017-07-10 04:10 +0200
      Re: metamail now misbehaving Steve Kleene <skdeb@syrano.acb.uc.edu> - 2017-07-10 14:50 +0200

#183467 — metamail now misbehaving

I run Wheezy with fvwm (window manager).  I prefer to use the command line
when possible, and for mail I have bsd-mailx with sendmail.  To read e-mails
sent as HTML or base64, I use metamail (which was last distributed with Etch,
I think), as follows:

  1. I save the e-mail to a file "mailfile".
  2. I call "metamail mailfile".
  3. Metamail silently extracts the HTML and saves it as, let's say, /tmp/Mu6MRTf.
  4. It calls "/usr/bin/iceweasel /tmp/MD7U6wY", which then displays the HTML.

Coincindent with my upgrade to firefox-esr 52, metamail no longer quite
works.  If no firefox window is up, it does succeed.  But if (as usual) a
firefox window already exists, it opens a new firefox tab with the error
"Firefox can't find the file at /tmp/Mu6MRTf".  And there is in fact no such
tmp file.

If I call "metamail -w mailfile", it offers to create /tmp/Mu6MRTf.  If I
approve that, I can then call "firefox-esr /tmp/Mu6MRTf" and see the HTML.  I
checked my backups, and updating firefox-esr caused no changes to
/etc/mailcap, ~/.mailcap, or the various redirects and alternatives for
firefox/iceweasel.

I'd be interested in any ideas on how to get this working again.  At the same
time, I expect that I will be advised give up on metamail.  I think
heirloom-mailx might be closest to what I already have.  To install that,
would I need to uninstall bsd-mailx first?  Can I assume that sendmail (and
sendmail.cf, etc.) will be left undisturbed?  I gather that mailutils and
mutt are other options.  I think mutt brings up its own window, and I'd
prefer to just use the command line for all the plain text e-mails I get.  On
the other hand, a better way to add attachments would be nice.  Currently I
do a lot of manual labor with the headers for those.

Thanks.

[toc] | [next] | [standalone]

#183473

On Sun 09 Jul 2017 at 14:12:07 (-0400), Steve Kleene wrote:
> I run Wheezy with fvwm (window manager).  I prefer to use the command line
> when possible, and for mail I have bsd-mailx with sendmail.  To read e-mails
> sent as HTML or base64, I use metamail (which was last distributed with Etch,
> I think), as follows:

[snip]

> I'd be interested in any ideas on how to get this working again.  At the same
> time, I expect that I will be advised give up on metamail.  I think
> heirloom-mailx might be closest to what I already have.  To install that,
> would I need to uninstall bsd-mailx first?  Can I assume that sendmail (and
> sendmail.cf, etc.) will be left undisturbed?  I gather that mailutils and
> mutt are other options.  I think mutt brings up its own window, and I'd
> prefer to just use the command line for all the plain text e-mails I get.  On
> the other hand, a better way to add attachments would be nice.  Currently I
> do a lot of manual labor with the headers for those.

I use mutt entirely in an xterm window. To read html emails, I have

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

in ~/.mutt/mailcap and get to them through the attachments menu,
ie, type v, select the html attachment and press return.
The only "downside" is that banks etc aren't made aware of my
reading their emails because I don't download the secret 1-pixel
images they typically include.

I compose emails in the same xterm with emacs by having

    set editor="emacs -nw -l $HOME/.emacs-email"

in ~/.mutt/muttrc, where my startup file sets textmode and linewrap.
Adding attachments is as simple as typing a and the name of the file
(with filename completion active) between closing the editor and
sending the email (or postponing it).

Cheers,
David.

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

#183484

On 2017-07-09 at 14:12 -0400, Steve Kleene wrote:
> I run Wheezy with fvwm (window manager).  I prefer to use the command line
> when possible, and for mail I have bsd-mailx with sendmail.  To read e-mails
> sent as HTML or base64, I use metamail (which was last distributed with Etch,
> I think), as follows:
> 
>   1. I save the e-mail to a file "mailfile".
>   2. I call "metamail mailfile".
>   3. Metamail silently extracts the HTML and saves it as, let's say, /tmp/Mu6MRTf.
>   4. It calls "/usr/bin/iceweasel /tmp/MD7U6wY", which then displays the HTML.
> 
> Coincindent with my upgrade to firefox-esr 52, metamail no longer quite
> works.  If no firefox window is up, it does succeed.  But if (as usual) a
> firefox window already exists, it opens a new firefox tab with the error
> "Firefox can't find the file at /tmp/Mu6MRTf".  And there is in fact no such
> tmp file.

I suspect metamail launches the browser and, after the launched program
is closed, automatically deletes the temporary file.
The problem is that when a window already exists, control is transfered
to that window, and the original program is closed, thus leading to a
race condition between the deletion of the temporary file and its
loading by the firefox process.

First option would be looking for a way not to have metamail remove the
file, leaving the file to be cleaned up later (you may want to dedicate
a subfolder for metamail temp files).

Another option would be to replace the call to /usr/bin/iceweasel with a
wrapper that launches iceweasel and waits a few seconds, which would
hopefully make the browser win the race. It's not a particularly elegant
solution (the race is still there, after all), but is probably good
enough for you.

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

#183511

On, Sun, 9 Jul 2017 14:12:07 -0400, I wrote:

>> I run Wheezy with fvwm (window manager).  I prefer to use the command line
>> when possible, and for mail I have bsd-mailx with sendmail.  To read e-mails
>> sent as HTML or base64, I use metamail (which was last distributed with Etch,
>> I think), as follows:
>> ...
>> Coincindent with my upgrade to firefox-esr 52, metamail no longer quite
>> works.  If no firefox window is up, it does succeed.  But if (as usual) a
>> firefox window already exists, it opens a new firefox tab with the error
>> "Firefox can't find the file at /tmp/Mu6MRTf".  And there is in fact no such
>> tmp file.

On, Mon, 10 Jul 2017 04:01:28 +0200 =?ISO-8859-1?Q?=C1ngel?= <debian-user@debian.16bits.net> replied:

> I suspect metamail launches the browser and, after the launched program
> is closed, automatically deletes the temporary file.
> The problem is that when a window already exists, control is transfered
> to that window, and the original program is closed, thus leading to a
> race condition between the deletion of the temporary file and its
> loading by the firefox process.
>
> First option would be looking for a way not to have metamail remove the
> file, leaving the file to be cleaned up later (you may want to dedicate
> a subfolder for metamail temp files).
>
> Another option would be to replace the call to /usr/bin/iceweasel with a
> wrapper that launches iceweasel and waits a few seconds, which would
> hopefully make the browser win the race. It's not a particularly elegant
> solution (the race is still there, after all), but is probably good
> enough for you.

A clever idea.  Option 2 was quick and successful.  In ~/.mailcap, I changed

text/html; /usr/bin/iceweasel '%s'; description=HTML Text; test=test -n "$DISPLAY";  nametemplate=%s.html

to

text/html; /usr/bin/iceweasel '%s'\; sleep 1; description=HTML Text; test=test -n "$DISPLAY";  nametemplate=%s.html

and now the tmp file hangs around long enough.

Thanks also to David Wright for the suggestions on setting up mutt.  I may
get to that, since bsd-mailx + metamail still has some real limitations.

[toc] | [prev] | [standalone]

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

csiph-web