On Monday, April 11, 2011 08:46:30 PM Duncan did opine:
> gene heskett posted on Mon, 11 Apr 2011 08:08:52 -0400 as excerpted:
> > Re my script. I didn't use pgrep, but $pidof, and it works, I can
> > start
>
> > and stop kmail and this script follows suit:
> ...snip script setup...
>
> > Cmd="/usr/lib/qt4/bin/qdbus org.kde.kmail /KMail
> > org.kde.kmail.kmail.checkMail" while :
> > do
> >
> > if [ $(pidof kmail) ]; then
> >
> > # I've found that stderr needs dumped to /dev/null, so
> > InMail=`/usr/bin/inotifywait -q -e close --format %f
${WatchDir}`
> > 2>&1 >/dev/null if [[ ${InMail} = 'gene' ]]
> > then
> >
> > $Cmd
> >
> > elif [[ ${InMail} = 'gene-from-linda' ]]
> > then
> >
> > $Cmd
> >
> > elif [[ ${InMail} = 'amanda' ]]
> > then
> >
> > ${Cmd}
> >
> > fi
> >
> > date -R >>${Mlog}/${Log}
> > echo ${InMail} >>${Mlog}/${Log}
> > InMail=''
> >
> > else
> >
> > sleep 3
> >
> > fi
> >
> > done
> > ================
> >
> > Even a blind man finds an apple occasionally. ;-)
> >
> > Now tear it up & chew me out, this kmail detection was todays
> > additions, the rest of it has been running here for about a year.
> > The diff?
> >
> > Now I can put it in /etc/rc.d/rc.local & quit running it by hand after
> > I get kmail started.
>
> As (deliberately, to keep the reply here shorter) explained in the
> reply to your "until" post, the above "while" loop is effectively
> an endless loop, due to the always-true ":" null-command.
>
> It works for what your after, because both branches of the "if"
> have delays (3s sleep if kmail isn't yet up, inotifywait, waiting
> for an event, when kmail is alive). I'm not absolutely sure if
> you discovered that as you tested, or if you just tested and
> went with what worked, not understanding the implications of
> your endless loop. As you said, even a blind man finds an apple
> occasionally...
No, the endless loop was intentional. That way, if kmail disappeared, it
would revert to the wait.
> I had originally thought you'd use until pgrep/pidof..., to wait
> until kmail appeared, then do the other stuff below. However,
> this actually works better, I think, because you accomplish
> in a single loop and an if, what I had in mind to do with two
> loops.
I did have two loops early in the session, but then the lights came on. :)
> Additionally, your version continues to work if you quit
> kmail (or it dies, or you logout of kde/X or it crashes
> so kmail quits as a result), then ultimately restart it, as
> in that case, the script simply switches back to three-second
> polling-for-kmail mode once again, and back to checking
> for mail once it appears again.
>
> That works one way while what I had in mind works another.
> Your way, you run this, as you said, from rc.local, and
> it continues to run, effectively as a daemon. The way
> I had in mind, the test for kmail would have been a
> one-shot, but could have been run either at kde startup
> (as originally discussed) or (with a simple addition that
> starts kmail itself) in place of the normal kmail binary.
I didn't want to putz too much with kmail. It can get all confused when
trying to force it into a one size fits all mold. I have some of those T-
Shirts too. ;-)
> So blind-man or not, I really like that apple you came
> across. It takes a different route than I had in mind,
> but ends up working as well, and arguably better.
>
> The one caveat is that it /is/ an endless loop, effectively
> running as a daemon. And just as with any daemon, in
> ordered to keep it from either interfering with shutdown or
> having to be caught by the the generic kill-anything-left
> logic, I'd suggest creating a daemon-stop script as well,
> that simply terminates this one, and put it in your
> stop-scripts.
A full kill would be both mailwatcher and inotiywait, in that order. But
it appears the kill-anything-left logic also handles it.
> Meanwhile, on the pidof/pgrep topic...
>
> pidof and pgrep are similar in function but different in detail.
>
> pidof is substantially simpler and less flexible, matching ONLY
> on the literal command name (name of the executable or symlink
> to it) itself.
Well, this is a case of needing a quick vim session to change the name(s).
> pgrep is FAR more flexible, not only because like grep it matches
> on regular expressions, but because it can optionally match
> against an entire command line, not just the executable name,
> because it can be
> user/group/terminal/session/oldest/newest/etc-limited, and
> because it can return not only PIDs but also process names
> (useful due to regex search for human consumption, thus
> avoiding an immediate ps to find the name of the returned pids,
> pidof of course operates on process names so returning what was
> fed into it in the first place makes little sense).
>
> So pgrep's hugely more flexible, but where pidof fits the need
> exactly, as here, there's little reason to invoke pgrep with its
> additional complexity.
Spot on I believe.
> Thanks for provoking me to do that comparison. I learned
> something myself by doing so. =:^)
>
> Finally, inotifywait...
>
> While I was aware of inotify, I hadn't really worked with it at
> all and don't even have an inotifywait commandline binary installed
> here. But now that I'm aware of it, a quick package search
> turns up inotify-tools, which presumably contains among other
> things the binary in question. I'll have to install and
> play with it. Thanks for the helpful cluein! =:^)
Be careful with it, and redirect any output path you don't need to
/dev/null. I have contacted the author, a student who was not aware of any
problems, advising him that its spitting some bad control chars out that
can screw up a konsole session pretty badly. But if any fresh release is
made, I suspect it will be after spring semester has been put to bed.
> One thing I've observed over the years that's so great about
> newsgroups and mailing lists is how often helping someone returns
> useful information in the other direction as well. I'm quite
> sure that's one of the reasons I've continued to find them
> so addictive, even as my own knowledge has continued to grow.
> No one knows everything, and one never knows when the next
> post one reads or the next post one replies to trying to help,
> will in turn reveal useful information of its own.
+100.
>
> Often, the useful info returned is simply a better understanding
> of the material one is helping others with. My dad was a teacher
> (now retired tho still volunteering at the local school a few
> days a week, health permitting), and I've never forgotten
> something he said, that the best way to learn something is to try
> to teach it to others. That's certainly true, as time and again
> replies on the newsgroups and lists have forced me to confront
> questions about material I already "knew" that I'd have never
> considered on my own.
:-)
> Other times, it's information I simply didn't know at all,
> previously.
>
> While I've certainly spent several hours replying in this thread,
> by now, both the above have been true. I know more about both
> pidof and pgrep as I've examined them based on your provocation,
> and I've learned about inotify-tools, something I was entirely
> unaware of before, tho I imagine I'd have been able to find
> them if I'd really /really/ needed them. But now I can place
> them in my toolbox to be used at my convenience, and I expect
> I /will/ find reason to use them, whereas otherwise I likely
> wouldn't have. =:^)
Precisely. My problem at my age is in recalling the tool 6 months later
when I need that function again, my short term memory has faded into the
sunset by then, so I find myself re-inventing stuff. And often, I go back
and look at the code 6 months later, and wonder if I was the idiot that
wrote it in the first place. ;-) My re-inventions usually work better
than the original... And if I have somebody to 'talk to', its quite often
that an un-related remark, might contain the seed of a better idea. I can
get into one of those can't see the forest through all these trees moods.
Writers block its been called...
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
<http://tinyurl.com/ddg5bz>
<http://www.cantrip.org/gatto.html>
Why do they call a fast a fast, when it goes so slow?
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
