4.6.2 early report

[gene heskett]

On Sunday, April 10, 2011 11:41:36 PM Duncan did opine:

> gene heskett posted on Sun, 10 Apr 2011 22:18:11 -0400 as excerpted:
> > That isn't where these need to be, they should start a few seconds
> > after kmail has been started.
> 
> That's simple enough.  Use sleep to delay, either alone with relatively
> dumb trial and error to determine how long, or with something like pgrep
> kmail in a loop, to see when kmail starts, and then another arbitrary
> delay after that to let kmail stabilize.  The script can then go in the
> usual startup location and spend most of its time sleeping, until kmail
> has time to come up.
> 
> With sleep, delays are never a problem, tho getting the length of the
> delay timed well enough to consistently have whatever it is you are
> waiting for happen first, without waiting far longer than necessary in
> most cases, /can/ be a bit of a challenge.  Here, pgrep in a delay loop
> of say one second is a convenient enough tool to detect when kmail
> starts, but one must still more or less guess at how long it takes to
> stabilize before one can run whatever it is you're intending to run.
> 
> Of course, if it's something that you're not actively waiting on, the
> time constraints tend to be rather less critical, and a simple sleep
> 30/60/90/120/300/whatever may well suffice.
> 
> (I'd call myself an intermediate shell (bash) scripter, as I do a
> reasonable amount of it both for my own use and occasionally for public
> use or in public bugfiling, as of gentoo initscript bugs, for instance,
> but like many intermediate users, I have enough knowledge on the topic
> to realize there's way more I don't know, and thus don't consider
> myself an expert.

Chuckle.  There are broadcast related things that I am an expert at, but 
cobbling up bash scripts is about the limit here on a 64 bit machine.  I 
usually manage to get the job done, but expert?  Dontbesilly...

> Use of sleep for a simple, dumb delay is beginner
> level shell scripting, creating a sleep loop with some sort of
> detection is arguably advanced beginner if not intermediate, with
> knowing about pgrep for that detection is probably intermediate, while
> advanced beginner level would use ps piped to grep. =:^)

I wasn't aware of pgrep, and it sounds like I could probably cobble up an 
initial test loop that would finally fall through when kmail gains a 
process number.  I'll work on that when I'm fresher, I did some mowing and 
small engine repairs here today & about wore the old man out.

The function ATM is a bash script that uses inotifywait to watch 
/var/spool/mail, and when something gets written to one of the mailfiles 
there, inotifywait exits and the next line of the script sends a d-bus 
message to kmail that sends it to read the mail.  This script then loops 
back to restart inotifywait again.  So rather than waiting several minutes 
in a timing loop before kmail checks the local spool file, I get my mail a 
fraction of a second after procmail writes what gets past spamassassin to 
the spool file.  kmail doesn't go away for 30 seconds to check the mail 
using this. :-)

But, if it gets started before kmail, then the d-bus socket isn't there and 
everything gets stuck.

-- 
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>
Out of sight is out of mind.
		-- Arthur Clough
___________________________________________________
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.