2

I have a app that calls an NSTask, (I have written the NSTask and App code) and the NSTask calls NSLog at places where I want a line written out to the console.

Problem is that I see the console message from the NSTask, then I see the same message output by the calling process, with a double header...

5/16/11 5:50:01 PM  theNSTask[7934] BLAH BLAH BLAH 
[0x0-0x256256].com.someid[7505] 2011-05-16 17:50:01.708 theNSTask[7934:903] BLAH BLAH BLAH

Super confusing just to read the desired output (BLAH BLAH BLAH). Is there a magic setting that fixes this problem?

Thanks,

--Tom

NSTask* task = [[NSTask alloc] init];
NSString* path = [[NSBundle mainBundle] pathForAuxiliaryExecutable:@"theNSTask"];
[task setLaunchPath:path];
NSMutableArray* arguments = [NSMutableArray array];
// get the dict as base64 string (start with binary plist):
NSString* base64Dict = [[self class] base64FromDictionary:message];
    [arguments addObject:base64Dict];
    [task setArguments:arguments];
[task launch];

[self.runningTasks addObject:task];
[task release];
Tom Andersen
  • 7,132
  • 3
  • 38
  • 55

1 Answers1

6

My guess is that the task is logging the messages directly to the console and also to its standard output, which by default is the same stream as the parent process's standard output, which your app is sending to the console.

If that's true, then you should be able to fix it by setting the task's standard output to /dev/null like:

NSFileHandle *nullFileHandle = [NSFileHandle fileHandleWithNullDevice];
[task setStandardOutput:nullFileHandle];
[task setStandardError:nullFileHandle];
Daniel Dickison
  • 21,832
  • 13
  • 69
  • 89
  • thanks - led me down the right path. For whatever reason, I had to call setStandardError:nullFileHandle]. Also I don't think that I have to close the null file handle, as its an auto released object, and also there is no actual file to close? – Tom Andersen May 18 '11 at 14:43
  • I guess the console logging is from standard error, instead of or in addition to standard output. Also, I think you're right that there's no need to close the file descriptor; I misinterpreted this sentence from [the reference](http://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSFileHandle_Class/Reference/Reference.html#//apple_ref/occ/clm/NSFileHandle/fileHandleWithNullDevice): "the file handle owns its associated file descriptor and is responsible for closing it." – Daniel Dickison May 18 '11 at 14:52