[kde] Re: 4.6.2 early report
- From: gene heskett <gheskett@xxxxxxxx>
- Date: Mon, 11 Apr 2011 00:00:41 -0400
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.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
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.
More info: http://www.kde.org/faq.html.
- [kde] Re: 4.6.2 early report
- From: Duncan
- [kde] Re: 4.6.2 early report
- Prev by Date: [kde] Re: 4.6.2 early report
- Next by Date: [kde] Re: 4.6.2 early report
- Previous by thread: [kde] Re: 4.6.2 early report
- Next by thread: [kde] Re: 4.6.2 early report