Re: Finding other apps' paths - deterministically!
Re: Finding other apps' paths - deterministically!
- Subject: Re: Finding other apps' paths - deterministically!
- From: "Michael Ash" <email@hidden>
- Date: Sun, 21 Sep 2008 18:08:56 -0400
On Sun, Sep 21, 2008 at 1:52 PM, Tommy Nordgren
<email@hidden> wrote:
>
> On Sep 21, 2008, at 6:36 AM, Michael Ash wrote:
>
>> On Sat, Sep 20, 2008 at 12:57 PM, Tommy Nordgren
>> <email@hidden> wrote:
>>>
>>> Use NSTask with the command line find -x / -name '*.app'
>>> Do this on a separate thread, and cache the result.
>>
>> I highly recommend against this approach. One problem is that it will
>> fail badly if any of the returned paths contain the \n character,
>
> Not true. With the given command line, find will return absolute
> paths.
> So this anomaly is easily detected when parsing find output
And what if it's the last character in a directory name?
>> which is a perfectly legal path character. For another it will fail if
>> the new process would exceed the user's process limit, a limit which
>> tends to be much lower than most other resource limits and thus much
>> easier to encounter in realistic situations.
>
> Firstly you can just increase the soft limit. Hard limits on Mac OS X
> is very generous.
> Secondly it would fail because maximum number of processes have been
> reached,
> you can simply retry later.
> I have never had a process break because it has reached the maximum
> allowed cpu-time,
> except in situations where I've deliberately set it very low,
You seem to have misunderstood the limit I'm talking about. I'm
talking about the limit on the number of processes, not anything else.
On my system, the number of processes per user is set at 266, and this
appears to be a hard limit. That limit is *extremely* easy to reach,
especially if you're running a bunch of poorly-written apps that spawn
subprocesses when they don't need to.
Retrying later is just silly. The amount of code to run 'find' with an
NSTask, read all its output, make some attempt at correcting \n
embedded in paths, and retry when the process can't spawn because
you've hit the process limit, is far more than the amount of code
you'd have to write to just directly iterate over the filesystem using
NSDirectoryEnumerator. What's the advantage supposed to be?
>> For the original problem, I'd recommend using something like
>> LSCopyApplicationURLsForURL() if it's at all possible. Of course maybe
>> you have data that isn't good for that, but if you can use it then
>> that's the way to go.
>>
>> If you must search the disk, use Spotlight if you can. It will be
>> vastly faster than anything else. The downside is that it won't work
>> if indexing is disabled or if the desired application is in an
>> excluded directory.
>>
> Using Spotlight to search for applications won't work, because some
> open-source
> packages install apps in directories that's not searched by spotlight,
> For example - the default install path for Qt is in directory
> /usr/local/Trolltech/Qt-<version-nr>
That's why I pointed this out when I suggested it.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden