• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Determining how the app is run (intel/ppc/rosetta/os version)?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Determining how the app is run (intel/ppc/rosetta/os version)?


  • Subject: Re: Determining how the app is run (intel/ppc/rosetta/os version)?
  • From: Gerben Wierda <email@hidden>
  • Date: Sun, 21 May 2006 15:09:00 +0200

On May 21, 2006, at 14:12 , Greg Hurrell wrote:

No chance of catching the exception with @try/@catch/@finally or NS_DURING/NS_HANDLER?

I am already preventing the exception by not passing nil arguments where this was OK in 10.2, raised a warning in 10.3 and now an exception in 10.4. But the nil value itself comes from using a corrupted NSData object that is delivered by a NSNotificationCenter that is used for handling the output of a subprocess, all afaik, nicely done according to Apple guidelines. The low level corrupted NSData object has now become circumspect, hence I want that solved, which is what I have asked DTS to help me with (so far without success).


In my own code that processes the output from AutorizationExecuteWithPrivileges() I've avoided the use of NSData and other high-level stuff entirely, depending on low-level funcitons like getc(), ferror() and feof() and finally I use CoreFoundation to pack it all into an NSString:

NSString* bufferLine = [(NSString *)CFStringCreateWithCString (NULL, inBuffer, kCFStringEncodingMacRoman) autorelease];

You may also need CFStringGetSystemEncoding() and GetApplicationTextEncoding() but kCFStringEncodingMacRoman has always worked for me with the output from commandline tools (I guess kCFStringEncodingUTF8 is another good candidate). Is there anyway you could avoid the freezes by taking an alternative route?

Maybe, but I needed a design where the higher level functions of the app should not be aware if output comes from an authorized or a normal subtask, if only because the user sometimes ha sa choice of doing the exact same subprocesses authorized (e.g. installing TeX in / usr/local) or unauthorized (e.g. installing TeX in your home directory). I also have many possibly simultaneous subtasks running. Hence, to simplify my design I wrote a layer on top of NSTask/ AutorizationExecuteWithPrivileges that to the rest of the app is an abstraction it works with. There is also the problem of synchronous and asynchronous subprocesses, e.g., one you have to wait for before returning to the user (there, getc() is OK) and others that run in the background but control is returned to the user, so getc() is not OK unless you want to write some polling app which does a low level read for data without waiting if there is no data yet). And you want to avoid anything that looks like waiting for output, getting output in sizeable chunks instead of whenever it is available, etc.


Anyway, I am curious if and how you handle (amongst others):
- getting the pid of your subprocess where the subprocesses are many, some slightly equivalent (e.g. checking GPG signatures with gpg or MD5 hashes on files with openssl).
- finding out if your subprocess is still running
- getting stderr and stdout separately from your subprocess as it runs and appending it to a view
- influencing the environment of your subprocess
In other words, the many of the things that NSTask can do.


Maybe someone has a decent NSAuthorizedTask lying around? (That would be quite a feat ;-)

G
_______________________________________________
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


  • Follow-Ups:
    • Re: Determining how the app is run (intel/ppc/rosetta/os version)?
      • From: Greg Hurrell <email@hidden>
References: 
 >Re: Determining how the app is run (intel/ppc/rosetta/os version)? (From: Gerben Wierda <email@hidden>)
 >Re: Determining how the app is run (intel/ppc/rosetta/os version)? (From: Greg Hurrell <email@hidden>)

  • Prev by Date: Re: Determining how the app is run (intel/ppc/rosetta/os version)?
  • Next by Date: Re: Determining how the app is run (intel/ppc/rosetta/os version)?
  • Previous by thread: Re: Determining how the app is run (intel/ppc/rosetta/os version)?
  • Next by thread: Re: Determining how the app is run (intel/ppc/rosetta/os version)?
  • Index(es):
    • Date
    • Thread