Re: Talking to the Dock
Re: Talking to the Dock
- Subject: Re: Talking to the Dock
- From: Sailor Quasar <email@hidden>
- Date: Tue, 29 Jul 2003 11:12:30 -0400
On Tuesday, July 29, 2003, at 10:46 AM, M. Uli Kusterer wrote:
I'm reasonably sure there's no Cocoa wrapper around it, but it would
probably be simpler to use NSTask to shell out to the 'ps' command.
sysctl() is a complicated set of multi-level options and data
structures, but the output of ps can be parsed easily since it's
possible to request specific information from ps and the output can
be distilled further using pipes into awk and grep. The only reason
to use sysctl() directly would be if speed is critical to the code in
question.
Maybe I spend too much time implementing parsers and have thus grown
allergic to them, but I generally find it much more convenient (and
reliable) to call "real" APIs than to call through to a command-line
tool.
To a point, yes. It's certainly much easier to call gethostbyname()
than to shell out to 'dig' and parse it's output. On the other hand,
sysctl() in terms of the process list is a rather involved operation,
including authorizing yourself as root if you want the full process
list instead of only the things the current user started. 'ps' is
already known to be safe and is setuid root.
Not to mention that I'm of the faction that says that speed is always
critical in application software, at least where it doesn't make the
code unreadable. I wouldn't switch to inline-assembly if it's not
really necessary, but otherwise I see no point in needlessly hogging
the user's CPU needlessly. I have enough applications that hog the CPU
excessively and without which I can't do. So chances are that if your
app needs more CPU than is warranted by its function, I'll throw it
away.
I don't think there's been a computer since the beige G3's that would
take perceptibly longer to ps|awk|grep than to AuthServices|sysctl(). A
macroscopic difference at the CPU level can be quite microscopic in
realtime.
But yes, if you don't care about subtle changes in the output of "top"
or "ps" screwing up your parsing, and you enjoy writing parsers that
take apart information that can be received already dissected from a
system API, and you don't care about it taking a little longer, NSTask
is a solution as well.
"Subtle changes" in the output of those commands would break a great
many more things than someone's use of NSTask. The output and options
of the BSD 'ps' command are well-known and long-standing. There have
been extensions, but never any that changed the basic structure of the
output. (Disclaimer: this is in my own knowledge only; someone more
versed in UNIX history may feel free to correct me :).
But if you want to see an example of a parser that isn't good enough,
check out the way PB doesn't report missing symbols. It simply says
"build failed" and leaves you to look in the raw gcc output what
actually went wrong...
That's Apple's sloppiness. I personally barely notice, since as a UNIX
junkie I'm always sifting through the raw build output anyway. I
recognize of course that some would be very put off by having to do
this (this is a shout-out to you, Larry! :). However, a little simple
care would easily prevent such a gross negligence.
On this same subject, I'm convinced Apple has no excuse for the bug you
mentioned. They've obviously learned how to pipe gcc's output into PB,
and the output of the ld subprocess is clearly defined and simple to
parse. At worst, they already added a great many extensions to gcc for
use of various mapfiles and such, if they were feeling really silly
they could have added another one to output an undefined symbol list.
Of course, on the flip side, I'm sure we'll all agree that PB is not a
finished product :).
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
-- Sailor Quasar, guardian of Leraz's memory
"A face of stone may hide a soul with the deepest Love of all"
Email: email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.