How to execute (shell) command when new mail arrives?
Harald Kirsch
checking for new mail once in a while. Is there a way of running
a shell command when mutt detects new mail such that I can have
a notification window pop up or change the icon used for the
terminal window?
Harald Kirsch
Ben Finney
> Is there a way of running a shell command when mutt detects new mail
> such that I can have a notification window pop up or change the icon
> used for the terminal window?
=====
$ apt-cache search mail | grep 'notif\(ier\|ication\)'
korn - Mail notifier for KDE
coolmail - Mail notifier with 3d graphics
sonicmail - email notifier GNOME applet
xyoubin - The conventional mail arrival notification client for X.
youbin - The conventional mail arrival notification server.
youbin-client - The conventional mail arrival notification client.
biff - a mail notification tool
gbiff - A mail notification program supported GTK+ and Gnome
melon - Mail notifier with configurable icons, xbiff replacement
wmmail - A mail notification program designed for WindowMaker
xlassie - Dockable mail notifier w/ message count & POP3/APOP/IMAP support
=====
Some or all of these should be available in your GNU/Linux or BSD
distribution.
--
\ "He who laughs last, thinks slowest." -- Anonymous |
`\ |
_o__) |
http://bignose.squidly.org/ 9CFE12B0 791A4267 887F520C B7AC2E51 BD41714B
Harald Kirsch
> On 2 Jul 2003 03:19:48 -0700, Harald Kirsch wrote:
> > Is there a way of running a shell command when mutt detects new mail
> > such that I can have a notification window pop up or change the icon
> > used for the terminal window?
>
> =====
> $ apt-cache search mail | grep 'notif\(ier\|ication\)'
Oops, it seems like my question was misleading.
I was after a way to run that command from mutt. I leave mutt
open all the time in a shell window which may or may not be iconified.
Mutt regularly scans the IMAP server for new mail.
It would like to beep when it finds new mail, but this is
annoying for colleagues in the same office, so I made sure
it cannot beep.
Instead of beeping, I would like mutt to execute a shell
command. Can this be done?
Harald.
Ben Finney
> Ben Finney wrote:
>> On 2 Jul 2003 03:19:48 -0700, Harald Kirsch wrote:
>> > Is there a way of running a shell command when mutt detects new
>> > mail such that I can have a notification window pop up or change
>> > the icon used for the terminal window?
>>
>> =====
>> $ apt-cache search mail | grep 'notif\(ier\|ication\)'
>
> Oops, it seems like my question was misleading.
Polite assumption, but no, your request was clear enough.
> I was after a way to run that command from mutt. I leave mutt open all
> the time in a shell window which may or may not be iconified.
Why not have the mail notifier running also? That way you'll know when
you have new mail even if you don't have Mutt running.
My point is: Mutt already performs its task; mail notifiers already
perform their task; why not use a mail notifier *and* Mutt?
I don't think Mutt can do what you ask without hacking it. You're free
to do so, of course -- this is free software -- but the functionality
you want already exists as a separate, specialised (and therefore
simple) tool, nicely packaged.
--
\ "I think it would be a good idea." -- Mahatma Gandhi (when |
`\ asked what he thought of Western civilization) |
Sven Guckes
> I was after a way to run that command from mutt.
"if your only tool is a hammer..."
> I leave mutt open all the time in a shell window which may or may not
> be iconified. Mutt regularly scans the IMAP server for new mail.
> It would like to beep when it finds new mail, but this is annoying
> for colleagues in the same office, so I made sure it cannot beep.
> Instead of beeping, I would like mutt to
> execute a shell command. Can this be done?
yes - it can be done. and it will issue
"rm -rf" in your account by default.
talk about trojan horses...
mutt is to do what the *user* tells it to do.
and it will do it when the users gives commands.
adding features where mutt would take action on
mails automatically while the user is absent
will almost certainly lead to disaster.
such features will therefore be deprecated.
Sven
Harald Kirsch
> * Harald Kirsch <pifp...@gmx.de>:
> > I was after a way to run that command from mutt.
>
> "if your only tool is a hammer..."
>
> > I leave mutt open all the time in a shell window which may or may not
> > be iconified. Mutt regularly scans the IMAP server for new mail.
> > It would like to beep when it finds new mail, but this is annoying
> > for colleagues in the same office, so I made sure it cannot beep.
> > Instead of beeping, I would like mutt to
> > execute a shell command. Can this be done?
>
> yes - it can be done. and it will issue
> "rm -rf" in your account by default.
> talk about trojan horses...
Interesting suggestion. This default setting
will be tedious to test.
>
> mutt is to do what the *user* tells it to do.
> and it will do it when the users gives commands.
That was exactly what I was after. I, the *user*, want to tell mutt
what to do when new mail arrives.
Harald Kirsch
Sven Guckes
> Sven Guckes <guc...@math.fu-berlin.de>:
>> mutt is to do what the *user* tells it to do.
>> and it will do it when the users gives commands.
>
> That was exactly what I was after. I, the *user*,
> want to tell mutt what to do when new mail arrives.
.. and then mutt will do something automatically while you
are not around. this is not what mutt was designed for.
this kind of action is better left to daemons or filters.
i just posted a few reasons here recently which show that such
actions are better left to other tools in this case mail filters.
and once you grasped that concept i am sure you will agree.
think about it: execution of arbitrary scripts
poses a vulnerability to the program.
this kind of features was actually considered
a security *bug* for the vim editor once.
ps: MIDs are quoted in the *header* to be read by programs.
Sven
Harald Kirsch
> > Sven Guckes <guc...@math.fu-berlin.de>:
> >> mutt is to do what the *user* tells it to do.
> >> and it will do it when the users gives commands.
> >
> > That was exactly what I was after. I, the *user*,
> > want to tell mutt what to do when new mail arrives.
>
> .. and then mutt will do something automatically while you
> are not around. this is not what mutt was designed for.
> this kind of action is better left to daemons or filters.
>
> think about it: execution of arbitrary scripts
> poses a vulnerability to the program.
> this kind of features was actually considered
> a security *bug* for the vim editor once.
The argument is kind of half-baked given that mutt has
the command:
pipe-message | pipe message/attachment to a shell command
Whether I do this while sitting in front of the terminal or whether
I specify this to be done automatically does not make much of a difference.
And with regard to automatic things: mutt automatically contacts the
server, reads message headers from it and displays them in the terminal.
I can only hope that it takes utmost care of what it renders and does
not send any arbitrary escape sequences to the terminal.
> ps: MIDs are quoted in the *header* to be read by programs.
Eeeeh, what?
Harald.
Sven Guckes
>> poses a vulnerability to the program.
>
> pipe-message | pipe message/attachment to a shell command
yes, the command exists - but the user has to issue it
himself. mutt does not issue this command on its own.
or does the description say that mutt issues
the command when it feels like it? right.
> Whether I do this while sitting in front of the terminal or whether I
> specify this to be done automatically does not make much of a difference.
i can see the bug reports now:
"... and suddenly all my data was gone."
"so what happened?"
"i dunno.."
"well, which commands did you type?"
"none."
"you mean, you did not issue *any* commands?"
"no, i did not type anything."
"but then mutt won't do anything!"
"well, there's this patch which will
make mutt do things automatically and.."
"hold it right here! you changed the
DNA of your dog and let it loose?"
"err, yes..."
"you IDIOT! this will be $20...
and don't come back here!"
and don't tell us we didn't warn you!
> And with regard to automatic things: mutt automatically contacts the
> server, reads message headers from it and displays them in the terminal.
next thing you'll us that mutt fetches mail from different servers
filters and changes the, checkes digi-sigs, and then makes coffee.
> I can only hope that it takes utmost care of what it renders
> and does not send any arbitrary escape sequences to the terminal.
huh? you want to make mutt issue arbitrary shell scripts
and also filter the output of those to take *care* of that?
reality check, please.
Sven
Harald Kirsch
> * Harald Kirsch <pifp...@gmx.de>:
> > server, reads message headers from it and displays them in the terminal.
>
> next thing you'll us that mutt fetches mail from different servers
> filters and changes the, checkes digi-sigs, and then makes coffee.
>
> > I can only hope that it takes utmost care of what it renders
> > and does not send any arbitrary escape sequences to the terminal.
>
> huh? you want to make mutt issue arbitrary shell scripts
> and also filter the output of those to take *care* of that?
>
> reality check, please.
Eeeh, hello, are you there? I only describe what mutt does already
right now. Apart from writing answers, you may want to consider
to read the postings you answer.
Harald Kirsch
Sven Guckes
> Sven Guckes <guc...@math.fu-berlin.de> wrote in message news:<2003-07-0...@guckes.net>...
>> * Harald Kirsch <pifp...@gmx.de>:
>> > And with regard to automatic things: mutt automatically contacts the
>> > server, reads message headers from it and displays them in the terminal.
>> > and does not send any arbitrary escape sequences to the terminal.
>>
>> huh? you want to make mutt issue arbitrary shell scripts
>> and also filter the output of those to take *care* of that?
>>
>> reality check, please.
>
> Eeeh, hello, are you there? I only describe what mutt does
> already right now. Apart from writing answers, you may
> want to consider to read the postings you answer.
vielleicht ist mein englisch zu schwer zu verstehen -
daher aussnahmsweise mal auf deutsch:
das pipe kommando ist *keine* automatisierung in mutt -
und es erlaubt daher *keine* automatische ausfuehrung.
der benutzer muss das *immer* selbst ausfuehren. und
wenn er sich damit in den fuss schiesst, dann ist er
*selber* schuld.
sollte man aber wirklich den einbau eine kommandos
erlauben, das automatisch in nicht-anwesenheit des
benutzers ausgefuehrt wird, dann kann man ueber die
konfiguration beliebige dinge einbauen, die
hoechst unschoene effekte ausloesen koennen
(zB set autocommand="rm -rf / &").
und daher ist das ganz eine *schlechte* idee
und wird daher auch *nicht* in mutt eingebaut.
klar jetzt?
ps: und gewoehn dir das zitieren
der MID im body endlich mal ab.
Sven
Ben Finney
> Sven Guckes <guc...@math.fu-berlin.de> wrote:
> > think about it: execution of arbitrary scripts poses a
> > vulnerability to the program. this kind of features was actually
> > considered a security *bug* for the vim editor once.
>
> The argument is kind of half-baked given that mutt has the command:
> pipe-message | pipe message/attachment to a shell command
Which must be invoked *by the user*, executing a conscious decision
based on whatever context they think appropriate at the time.
> Whether I do this while sitting in front of the terminal or whether I
> specify this to be done automatically does not make much of a
> difference.
It makes a massive difference. It is the major difference between Mutt
and a virus-propogation program like Outlook. If arbitrary commands can
be executed automatically, the user has made no decision in the context
of that particular message.
> And with regard to automatic things: mutt automatically contacts the
> server, reads message headers from it and displays them in the terminal.
> I can only hope that it takes utmost care of what it renders and does
> not send any arbitrary escape sequences to the terminal.
Much of the care taken is in the simplification, excruciatingly detailed
specification, and critical appraisal of the protocols used in such
automated connections. SMTP, POP3 and IMAP are single-purpose,
narrowly-defined protocols explicitly designed for automatic, unattended
operation.
The Mutt pipe-message function is *not*. It is a deliberately broad
function, allowing execution of arbitrary programs by the user,
*interactively*, when they can make a conscious decision about what it
is they're doing.
> > ps: MIDs are quoted in the *header* to be read by programs.
> Eeeeh, what?
Your attribution line needlessly includes the Message-ID of the message
you're following up, when this information is already in the Followup-To
header of your own message. A bit of visual clutter that can be
removed (as I've done in my followup to your followup), preferably by
not including it in the first place.
--
\ "A man may be a fool and not know it -- but not if he is |
`\ married." -- Henry L. Mencken |
Jeff Davis
>
> vielleicht ist mein englisch zu schwer zu verstehen -
> daher aussnahmsweise mal auf deutsch:
I've never had a problem understanding your English Sven...
but the German is too hard! :-)
Bester Respekt!
Jeff
Alan Connor
Boy, THAT'S a big help.
:-)
How about:
#!/bin/bash
echo "...." | mutt sa...@kraut.com -s "Woof!"
exit 0
??
From you own webpage, minus the script stuff.
Alan
--
There's no place like ~
Sven Guckes
[kraut response]
> Boy, THAT'S a big help. :-)
well, i've tried...
> How about:
> #!/bin/bash
> echo "...." | mutt sa...@kraut.com -s "Woof!"
> exit 0
no, that won't help.
the request is not about using mutt for automated sending -
but automating anything when new mail arrives in mutt.
like, "do whatever when new mails comes in" as in "simulate
a mail filter and execute arbitrary shell scripts".
Sven
Harald Kirsch
> >> > And with regard to automatic things: mutt automatically contacts the
> >> > server, reads message headers from it and displays them in the terminal.
> >> > I can only hope that it takes utmost care of what it renders
> >> > and does not send any arbitrary escape sequences to the terminal.
> >>
> >> huh? you want to make mutt issue arbitrary shell scripts
> >> and also filter the output of those to take *care* of that?
> >>
> >> reality check, please.
> >
> > Eeeh, hello, are you there? I only describe what mutt does
> > already right now. Apart from writing answers, you may
> > want to consider to read the postings you answer.
>
> vielleicht ist mein englisch zu schwer zu verstehen -
> daher aussnahmsweise mal auf deutsch:
Your english is ok, as far as I am concerned.
>
> das pipe kommando ist *keine* automatisierung in mutt -
I understood this very well and was in no way referring any
more to the pipe command. I was referring to mutt's
automatic check for new mail which, when imap is used,
involves contacting a server, reading data from it and even
sending it to another program on my computer, namely rxvt.
So much for mutt not doing anything automatic. Of course this
is of a slightly different quality than executing arbitrary commands,
but since escape
sequences can change the window title of an rxvt (or xterm afaik)
this could even influence the window manager, which may be programmed
to take some action on a title change ... Well, I assume mutt takes care
not to let any arbitrary escape sequences escape through to the
subject lines it writes to my terminal while I am away.
The point is, there is always a tradeoff between usability and
security. While MS rather blindly goes for usability, mutt
rather goes for security, which I like. But the case is not
necessarily as clear cut as you seem to think, given your reaction.
> und daher ist das ganz eine *schlechte* idee
> und wird daher auch *nicht* in mutt eingebaut.
I never asked for anything to be implemented in mutt. I only
asked whether a certain functionality is available or not and
could have lived with a simple "no, not possible" as was posted
in that other thread. Then you jumped in and declared that
this feature was a dump idea in a tone which asked for opposition.
> klar jetzt?
>
> ps: und gewoehn dir das zitieren
> der MID im body endlich mal ab.
You should seriously consider changing your
discussion manners. Keep calm, read other people's messages
carefully, don't try to show off by using acronyms,
don't take every mention of a not-existing
feature in mutt as a personal offence and try not to be
the "Oberlehrer".
Kind Regards,
Harald Kirsch
Harald Kirsch
> On 5 Jul 2003 02:27:34 -0700, Harald Kirsch wrote:
> > > ps: MIDs are quoted in the *header* to be read by programs.
> > Eeeeh, what?
>
> Your attribution line needlessly includes the Message-ID of the message
> you're following up, when this information is already in the Followup-To
> header of your own message.
Ahh, well, I'll try to improve on this. Maybe someone should tell
the google guys to change the message posting default.
Thanks,
Harald.
(Let's see which troll now comes along spitting at me because
I use google to read news.-)
Peter H. Coffin
but... procmail works *all the time*, not just when mutt is running.
--
51. If one of my dungeon guards begins expressing concern over the conditions
in the beautiful princess' cell, I will immediately transfer him to a
less people-oriented position.
--Peter Anspach's list of things to do as an Evil Overlord
Sven Guckes
> I was referring to mutt's automatic check for new mail which,
> when imap is used, involves contacting a server, reading data
> from it and even sending it to another program on my computer,
> namely rxvt. So much for mutt not doing anything automatic.
(jeez... what's next?) yes - mutt even forgets your passphrase
after N seconds - automatically and without the user noticing.
and it keeps scanning for the user's input *all* the time. duh!
> Of course this is of a slightly different
> quality than executing arbitrary commands..
yes - you got it! that *exactly* was my *point*!
(now, - was this so hard to tell from my post?)
> but since escape sequences can change the window title of an rxvt (or
> xterm afaik) this could even influence the window manager, which may
> be programmed to take some action on a title change ... Well, I assume
> mutt takes care not to let any arbitrary escape sequences escape
> through to the subject lines it writes to my terminal while I am away.
(is this guy for real? seriously? alright, let's play along..)
<mode type=security flavor=microsoft>
sure - it even scans the escape codes the terminal receives
from other programs. thus it makes your terminal safe[tm].
we would have called it security-dog - but that was too long.
we though of kerberos, too, but that someone was a problem, too..
</mode>
> The point is, there is always a tradeoff between usability and
> security. While MS rather blindly goes for usability, mutt
> rather goes for security, which I like. But the case is not
> necessarily as clear cut as you seem to think, given your reaction.
talk about clear cut. this functionality would
not be within mutt if it wasn't for some whiners.
if i was maintainer of mutt then you'd have to
request updates from the server *yourself* -
or get yourself a patch from somewhere. so there.
> I never asked for anything to be implemented in mutt.
> I only asked whether a certain functionality is
> available or not and could have lived with a simple
> "no, not possible" as was posted in that other thread.
"no, not possible". happy now?
Sven [actually, it's "yes, it's possible -
but, noo, it's not a good idea because.."]
Sven Guckes
> On 7 Jul 2003 09:41:04 GMT, Sven Guckes wrote:
>> the request is not about using mutt for automated sending -
>> but automating anything when new mail arrives in mutt.
>> like, "do whatever when new mails comes in" as in "simulate
>> a mail filter and execute arbitrary shell scripts".
>
> but... procmail works *all the time*, not just when mutt is running.
tell me about it! better yet - tell harry "google post" cherry.
Sven
Alan Connor
> * Alan Connor <xxx...@xxxx.xxx>:
> [kraut response]
8-)
>> Boy, THAT'S a big help. :-)
>
> well, i've tried...
>
>> How about:
>> #!/bin/bash
>> echo "...." | mutt sa...@kraut.com -s "Woof!"
>> exit 0
>
> no, that won't help.
>
> the request is not about using mutt for automated sending -
> but automating anything when new mail arrives in mutt.
> like, "do whatever when new mails comes in" as in "simulate
> a mail filter and execute arbitrary shell scripts".
>
> Sven
I realize that this has been covered, but what the h??l is wrong with using
procmail/formail? These are WONDERFUL tools and if *I* can use them, ANYONE
can use them. They are also extremely well documented.
For the OP:
man procmail
man procmailrc
man procmailex
.fetchmailrc ------>
poll pop.earthlink.net
tracepolls
proto pop3
user "me@my_isp"
pass "yours"
is your_username here
and wants mda "/usr/bin/formail -ds /usr/bin/procmail"
fetchall
--------------
Sven Guckes
> On 7 Jul 2003 09:41:04 GMT, Sven Guckes <guc...@math.fu-berlin.de>:
>> the request is not about using mutt for automated sending -
>> but automating anything when new mail arrives in mutt.
>> like, "do whatever when new mails comes in" as in "simulate
>> a mail filter and execute arbitrary shell scripts".
>
> is wrong with using procmail/formail? These are WONDERFUL
> tools and if *I* can use them, ANYONE can use them.
> They are also extremely well documented.
the OP insists on making his mutt to do all this.
maybe he should use this old OS thing... where every
program tends to be a solution for everything..
what was the name again? i keep forgetting...
Sven [wondering when "xxx" will become a valid TLD]
Alan Connor
:-0
I hate that trend in Linux. It is pure illusion. One part of the
Master Program fails and the whole thing is worthless. I don't need my
browser to do ftp. I have a great ftp client that works just fine.....
Don't use KDE or GNOME or Emacs or whateever.
Just a nice xterm and a minimal x install. My "desktop environment" is a
case script that pops up with 2 keystrokes and a list of aliases/vars/scripts\
/functions that takes 2 keystrokes to bringup.
For what it's worth, I do call mutt from procmail to include explanatory files
with the spam it forwards to junkmail@my_isp. For example:
:0
* ^From.*[mM][iI][cC][rR][oO][sS][oO][fF][tT]
* ! ^X-Loop: alanc...@earthlink.net
| mutt junk...@earthlink.net -s "Please Hammer These Bozos" -i /home/alanc/ju
nkmail
David Combs
Ben Finney <bignose-h...@and-zip-does-too.com.au> wrote:
>On 3 Jul 2003 01:37:28 -0700, Harald Kirsch wrote:
>> Ben Finney wrote:
>>> On 2 Jul 2003 03:19:48 -0700, Harald Kirsch wrote:
>>> > Is there a way of running a shell command when mutt detects new
>>> > mail such that I can have a notification window pop up or change
>>> > the icon used for the terminal window?
>>>
>>> =====
>>> $ apt-cache search mail | grep 'notif\(ier\|ication\)'
>>
>> Oops, it seems like my question was misleading.
>
>Polite assumption, but no, your request was clear enough.
>
>> I was after a way to run that command from mutt. I leave mutt open all
>> the time in a shell window which may or may not be iconified.
>
>Why not have the mail notifier running also? That way you'll know when
>you have new mail even if you don't have Mutt running.
>
>My point is: Mutt already performs its task; mail notifiers already
>perform their task; why not use a mail notifier *and* Mutt?
Could you please name (and give urls for?) for one or more
of these "mail notifiers" (first time I've heard the term),
maybe also saying which one *you* like best (and why?).
Thanks,
David
Ben Finney
> Could you please name (and give urls for?) for one or more of these
> "mail notifiers" (first time I've heard the term)
Perhaps the most notable, and certainly one of the earliest, was the BSD
utility "biff" (named after a dog at UC Berkeley).
<http://www.catb.org/~esr/jargon/html/B/biff.html>
To this day, many mail notification programs are described as "a
biff-like utility [...]", so often searching your package database for
the term "biff" will turn up many of them.
> maybe also saying which one *you* like best (and why?).
Like the original poster, I use gkrellm on my desktop to notify me of
many aspects of the system, and its mail notifier is quite flexible:
--
\ "Time wounds all heels." -- Groucho Marx |
`\ |
David Combs
David Combs <dkc...@panix.com> wrote:
>In article <slrnbhuh8q.tuj.b...@iris.polar.local>,
>Ben Finney <bignose-h...@and-zip-does-too.com.au> wrote:
>>
>>Like the original poster, I use gkrellm on my desktop to notify me of
>>many aspects of the system, and its mail notifier is quite flexible:
>>
>> <http://gkrellm.net/>
>>
>
>
>I'll now try google.
>
>Thanks!
>
>David
>
Uh, helps if I spell it correctly; it has TWO l's.
Found it.
Seems like (not just from its gk-prefix) that it runs
under a gui, namely gtk.
(1) Leads to a question -- what does one use (what would *you* use)
if you read mail, etc, all via a *shell account*?
No gui there -- it's all in, well, not line-mode, more than that
since vi, mutt, etc all works "two dimensionally" ok, but it
sure isn't a gui.
Suggestions?
-----
(2) About using gkrellm for other than mail, on my sun box:
Anyone reading this who uses Solaris (9) -- seems to have
a bunch of gtk stuff under "sfw".
Quick hints on how to run it?
Thanks!
David
Ben Finney
> what does one use (what would *you* use) if you read mail, etc, all
> via a *shell account*?
The terminal multiplexer ("window manager"), GNU screen:
<http://www.gnu.org/software/screen/>
<http://www.math.fu-berlin.de/~guckes/screen/>
allows me to run several full-screen terminal processes on the one
session. Thus, I have one screen "window" constantly running Mutt,
which itself checks my local mailboxes for new messages.
Another screen windows runs slrn, allowing me to keep an eye on
newsgroups.
Other screen windows run editors, log file viewers, shell prompts with
whatever work I'm doing, et cetera.
Highly recommended. And all operable exactly the same way over a remote
session, allowing me to do all this via SSH from work :-)
--
\ "Outside of a dog, a book is man's best friend. Inside of a |
`\ dog, it's too dark to read." -- Groucho Marx |
_o__) |
Ben Finney <http://bignose.squidly.org/>