Re: NSTask stealth bug in readDataOfLength!! :(
Re: NSTask stealth bug in readDataOfLength!! :(
- Subject: Re: NSTask stealth bug in readDataOfLength!! :(
- From: "Theodore H. Smith" <email@hidden>
- Date: Wed, 25 Oct 2006 20:49:42 +0100
On 25 Oct 2006, at 20:28, Stephen Deken wrote:
If it's a perfectly good API, then why did Alastair say this:
Ok. It's a perfectly good API that has at least one bug. Actually,
if it really is a SIGCHLD or SIGPIPE that's causing it, it's more
properly a 'gotcha', since it's working as designed but trips up lots
of developers. If this is the problem, you can mask the signals out
during the call and get on with it.
Err... OK. That'd be a new one to me. Also too late as I already got
a solution using system() and using the > operator to pipe to a file.
Also, I find the API very awkward. Using 5 classes (NSPipe, NSArray,
NSFileHandle, NSData, NSTask), just to get a string? Ideally, we'd
have a simple function like this:
I agree, if all you need is the contents of stdout, then NSTask is
unwieldy. But it can do a lot more than just that, which is why the
class is structured the way it is. But you can mitigate the mess it
creates in your code by adding a category.
NSString* NSSystem( NSString* PathArgumentsAndEverything );
it would return the stdout :)
What happens if the executable returns an error code? What happens if
the executable crashes? What happens if the executable gets thrown
into an infinite loop? What happens if the executable outputs an
infinite stream of data? What happens if the executable is not found?
What happens if the executable prints to stderr instead of stdout?
What happens if the executable needs input?
Then you use a more complete API?
I like APIs that are easy for easy things, and give more features for
more complex things, but don't impose them.
OK ideally, we could just use one class:
NSTask* t = [NSTask taskWithString: @"/usr/bin/curl --url bla"];
NSData* d = [t launchAndResultData];
If you got an error code, you'd read it like this:
int Error = [t errorCode];
If it goes into an infinite loop... well then you'd use the standard
notification thingy you use at the moment.
If there's no executable it would return nil from taskWithString.
If it prints to stderr, you'd use the current API for redirecting
stderr. Same with with input, use what it's currently got.
Just two more methods would cut out 3 classes required!!!
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden