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.
