Dir of app

  • How does one find the directory of a the application one is in through
    Objective-C?  I'd like to use it to build up file paths.

    thanks,
    wes
  • Le 18 déc. 07 à 12:28, Wesley Smith a écrit :

    > How does one find the directory of a the application one is in through
    > Objective-C?  I'd like to use it to build up file paths.
    >
    > thanks,
    > wes

    See NSBundle documentation
  • Wesley Smith wrote:

    > How does one find the directory of a the application one is in through
    > Objective-C?  I'd like to use it to build up file paths.

    As someone else noted, the way to do that is through NSBundle or
    CFBundle.

    But it should also be pointed out that there are very few tasks for
    which "find the path of the app" is part of the correct solution.

    What are you really trying to do? What kind of file paths are you
    intending to build relative to the path of your executable?

    G
  • >> How does one find the directory of a the application one is in through
    >> Objective-C?  I'd like to use it to build up file paths.
    >
    > As someone else noted, the way to do that is through NSBundle or
    > CFBundle.
    >
    > But it should also be pointed out that there are very few tasks for
    > which "find the path of the app" is part of the correct solution.
    >
    > What are you really trying to do? What kind of file paths are you
    > intending to build relative to the path of your executable?

    Well, in the app I'm building, there are alot of scripts that are
    going to be kept in 1 of 2 places depending on if they should be
    touched by the user or not.  One will be in the resources folder
    inside the app folder and the other will be in a subfolder of the
    app's folder in /Applications.  Here's the basic layout:

    /Applications/App/
                          App/Contents/Resources/Scripts      <----
    scripts the app uses internally
                          Scripts
    <----- user scripts

    The application is basically a shell of a Cocoa app with Lua running
    inside it.  Everything is completely configured through scripts and
    I'd like to have a few directories that are standard with the app
    where a user can throw scripts in and have them automatically in the
    search paths of the app.  Of course, more search paths can be added by
    the user, but at the minimum I want there to be 1 directory that the
    app always knows about and the cleanest way to do that is to define a
    folder relative to the app location.  There are a number of apps for
    OSX that follow this same convention so I don't think it's unusual at
    all but if you have any other ideas for how to handle this, I'd love
    to hear them.

    Also, I know Leopard has an entire event notification mechanism for
    file modification.  Is there something like this on Tiger as well?

    best,
    wes
  • An alternative would be /Library/Scripts for scripts run by the user.

    -wil

    On Dec 18, 2007, at 11:11 AM, Wesley Smith wrote:

    >>> How does one find the directory of a the application one is in
    >>> through
    >>> Objective-C?  I'd like to use it to build up file paths.
    >>
    >> As someone else noted, the way to do that is through NSBundle or
    >> CFBundle.
    >>
    >> But it should also be pointed out that there are very few tasks for
    >> which "find the path of the app" is part of the correct solution.
    >>
    >> What are you really trying to do? What kind of file paths are you
    >> intending to build relative to the path of your executable?
    >
    >
    > Well, in the app I'm building, there are alot of scripts that are
    > going to be kept in 1 of 2 places depending on if they should be
    > touched by the user or not.  One will be in the resources folder
    > inside the app folder and the other will be in a subfolder of the
    > app's folder in /Applications.  Here's the basic layout:
    >
    > /Applications/App/
    > App/Contents/Resources/Scripts      <----
    > scripts the app uses internally
    > Scripts
    > <----- user scripts
    >
    >
    > The application is basically a shell of a Cocoa app with Lua running
    > inside it.  Everything is completely configured through scripts and
    > I'd like to have a few directories that are standard with the app
    > where a user can throw scripts in and have them automatically in the
    > search paths of the app.  Of course, more search paths can be added by
    > the user, but at the minimum I want there to be 1 directory that the
    > app always knows about and the cleanest way to do that is to define a
    > folder relative to the app location.  There are a number of apps for
    > OSX that follow this same convention so I don't think it's unusual at
    > all but if you have any other ideas for how to handle this, I'd love
    > to hear them.
    >
    > Also, I know Leopard has an entire event notification mechanism for
    > file modification.  Is there something like this on Tiger as well?
    >
    > best,
    > wes
  • On Dec 18, 2007, at 2:11 PM, Wesley Smith wrote:

    > Well, in the app I'm building, there are alot of scripts that are
    > going to be kept in 1 of 2 places depending on if they should be
    > touched by the user or not.  One will be in the resources folder
    > inside the app folder and the other will be in a subfolder of the
    > app's folder in /Applications.  Here's the basic layout:
    >
    > /Applications/App/
    > App/Contents/Resources/Scripts      <----
    > scripts the app uses internally
    > Scripts
    > <----- user scripts
    >
    >
    > The application is basically a shell of a Cocoa app with Lua running
    > inside it.  Everything is completely configured through scripts and
    > I'd like to have a few directories that are standard with the app
    > where a user can throw scripts in and have them automatically in the
    > search paths of the app.  Of course, more search paths can be added by
    > the user, but at the minimum I want there to be 1 directory that the
    > app always knows about and the cleanest way to do that is to define a
    > folder relative to the app location.  There are a number of apps for
    > OSX that follow this same convention so I don't think it's unusual at
    > all but if you have any other ideas for how to handle this, I'd love
    > to hear them.

    For the internal scripts, you shouldn't be building paths manually.
    You should use the utility methods provided by NSBundle, invoked on
    your app's main bundle.

    For external scripts, I don't agree that "the cleanest way to do that
    is to define a folder relative to the app location." I think the
    cleanest way to do it is to document that your app will look for user-
    provided scripts in /Library/Application Support/YourApp and ~/
    Library/Application Support/YourApp and then do so. You're correct
    that there *are* a number of apps that behave like you plan to, but
    that number is quite small and I'd suggest that a lot of people are
    annoyed by support folders cluttering up /Applications or by app's
    requiring that they be in specific locations, absolute or relative to
    some other information.
  • Plus it makes updating your program harder, since drag and drop
    replacement of the app bundle with a new release deletes all of those
    custom scripts. And then there's the issue of global versus user
    scripts -- keeping everything in the app bundle makes it impossible
    to have secure per-user customization since anyone with admin rights
    can delete anyone else's scripts.

    On Dec 18, 2007, at 3:12 PM, Gregory Weston wrote:

    > For the internal scripts, you shouldn't be building paths manually.
    > You should use the utility methods provided by NSBundle, invoked on
    > your app's main bundle.
    >
    > For external scripts, I don't agree that "the cleanest way to do
    > that is to define a folder relative to the app location." I think
    > the cleanest way to do it is to document that your app will look
    > for user-provided scripts in /Library/Application Support/YourApp
    > and ~/Library/Application Support/YourApp and then do so. You're
    > correct that there *are* a number of apps that behave like you plan
    > to, but that number is quite small and I'd suggest that a lot of
    > people are annoyed by support folders cluttering up /Applications
    > or by app's requiring that they be in specific locations, absolute
    > or relative to some other information.
  • Wesley,
    You asked a second question about file modification notification. As
    you know, Leopard has FSEvents. In Tiger (and possibly earlier Mac OS
    releases as well) there is a kernel event notification system called
    "kqueue". You can "man kqueue" to get more info. But for us Cocoa
    developers, Uli Kusterer has created a nice wrapper which is available
    at http://www.zathras.de/angelweb/sourcecode.htm#UKKQueue.  I use this
    in my application.

    Alan Pearson (<alanp...>)
    http://www.sonzea.com/

    On Dec 18, 2007, at 11:11 AM, Wesley Smith wrote:
    >
    > Also, I know Leopard has an entire event notification mechanism for
    > file modification.  Is there something like this on Tiger as well?
    >
    > best,
    > wes
  • Am 18.12.2007 um 21:33  schrieb Justin Anderson:
    > Plus it makes updating your program harder, since drag and drop
    > replacement of the app bundle with a new release deletes all of
    > those custom scripts. And then there's the issue of global versus
    > user scripts -- keeping everything in the app bundle makes it
    > impossible to have secure per-user customization since anyone with
    > admin rights can delete anyone else's scripts.

      Another issue is that non-Admin users wouldn't even be able to edit
    a folder in /Applications, nor the application itself.

    Cheers,
    -- M. Uli Kusterer
    "The Witnesses of TeachText are everywhere..."
    http://www.zathras.de
  • > You asked a second question about file modification notification. As
    > you know, Leopard has FSEvents. In Tiger (and possibly earlier Mac OS
    > releases as well) there is a kernel event notification system called
    > "kqueue". You can "man kqueue" to get more info. But for us Cocoa
    > developers, Uli Kusterer has created a nice wrapper which is available
    > at http://www.zathras.de/angelweb/sourcecode.htm#UKKQueue.  I use this
    > in my application.

    Thanks for this info.  It works beautifully!  One question about the
    sequencing of these events.  I'm watching a file while a text editor
    saves it and get 2 notifications:

    2007-12-18 23:39:14.324 luaAV[1461] Watching
    UKKQueueFileAttributesChangedNotification
    2007-12-18 23:39:14.325 luaAV[1461] Watching UKKQueueFileDeletedNotification

    Why would I get a UKKQueueFileDeletedNotification after a
    UKKQueueFileAttributesChangedNotification?  That seems odd to me and
    if I hadn't known better I would have naively programmed logic in my
    app thinking that the file no longer existed but it is definitely
    still there. Any clues?

    thanks,
    wes
  • >> Why would I get a UKKQueueFileDeletedNotification after a
    >> UKKQueueFileAttributesChangedNotification?  That seems odd to me and
    >> if I hadn't known better I would have naively programmed logic in my
    >> app thinking that the file no longer existed but it is definitely
    >> still there. Any clues?
    >
    > Very likely safe-save. There is support to save a file and swap its
    > name and file-id before deleting the old file. This way, if the save
    > fails in the middle (say you loose power) the original file is still
    > on the disk. The new file only becomes the old file after the data has
    > been written out (probably to the cache -- not necessarily the disk,
    > unless the app actual forces a flush).
    >

    Ah.  This makes sense.  So are there properties of the file in
    question I can query to keep track of all of this?

    thanks again,
    wes
previous month december 2007 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Go to today