4.6.2 early report

gene heskett gheskett at wdtv.com
Tue Apr 12 02:11:03 BST 2011

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

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

More information about the kde mailing list