4.6.2 early report

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