4.6.2 early report

[Duncan]

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

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.

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.

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.

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.

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.

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! =:^)

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.  =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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