what's the standard way to load resources - Unix

This is a discussion on what's the standard way to load resources - Unix ; Hi, all: I'm new to *nix environment programming. I not sure what's the correct way to load resources. For example, after installation an application's layout as below: /(prefix)/bin/my_app /(prefix)/share/my_app/icons/a.png /(prefix)/share/my_app/ui/a.glade How to write code to load a.png/a.glade correctly(the path) regardless ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: what's the standard way to load resources

  1. what's the standard way to load resources

    Hi, all:
    I'm new to *nix environment programming. I not sure what's the correct
    way to load resources. For example, after installation an
    application's layout as below:

    /(prefix)/bin/my_app
    /(prefix)/share/my_app/icons/a.png
    /(prefix)/share/my_app/ui/a.glade

    How to write code to load a.png/a.glade correctly(the path) regardless
    whatever prefix choose when installation?

  2. Re: what's the standard way to load resources

    Andrew Gabriel wrote:
    >Often, /(prefix) is compiled in to the binary so it knows.
    >[snip]
    >Another way is to have an optional environment variable to
    >override other search methods, in case that's required.


    I've also seen apps make a variety of guesses at the prefix at startup
    by looking through all places the app is most likely to be installed.

    -Beej


  3. Re: what's the standard way to load resources

    Jarod Liu writes:

    > Hi, all:
    > I'm new to *nix environment programming. I not sure what's the correct
    > way to load resources. For example, after installation an
    > application's layout as below:
    >
    > /(prefix)/bin/my_app
    > /(prefix)/share/my_app/icons/a.png
    > /(prefix)/share/my_app/ui/a.glade
    >
    > How to write code to load a.png/a.glade correctly(the path) regardless
    > whatever prefix choose when installation?


    I assume the problem is finding .

    The most robust and portable way I know to find is for my_app to
    be a shell script which use $0 to get the path to the script and then
    launch the executable. And that's not fool proof (one problem being
    symbolic links... but whatever methods you end up using, you'll have to
    define what you do with symbolic links -- do you accept /share to
    be a symbolic link? and /bin? and having launch my_app through a
    symbolic link to /bin/my_app? I've seen some people do that and
    then complain if it doesn't work). And if my_app uses dynamic libraries in
    /lib, that could even be the only way to launch it if you don't
    want users to have to set up things.

    You can be less portable and use things like /proc/self/exe under Linux or
    /proc/$$/path/a.out under Solaris which are symbolic links to the
    executable.

    Then you can start from argv[0] and use the fact that's usually what the
    user typed. So if it is relative, it's to the current directory. If it is
    a simple filename, it has been searched in the PATH.

    Yours,

    --
    Jean-Marc

  4. Re: what's the standard way to load resources

    On 27 Oct 2008 10:14:53 GMT, andrew@cucumber.demon.co.uk (Andrew Gabriel) wrote:
    > In article ,
    > Jarod Liu writes:
    >> Hi, all:
    >> I'm new to *nix environment programming. I not sure what's the
    >> correct way to load resources. For example, after installation an
    >> application's layout as below:
    >>
    >> /(prefix)/bin/my_app
    >> /(prefix)/share/my_app/icons/a.png
    >> /(prefix)/share/my_app/ui/a.glade
    >>
    >> How to write code to load a.png/a.glade correctly(the path)
    >> regardless whatever prefix choose when installation?

    >
    > I don't think there's one golden rule.
    >
    > Often, /(prefix) is compiled in to the binary so it knows.
    >
    > It is probably also a good idea to allow the tree to be relocatable,
    > in which case try constructing paths relative to the execuatable's
    > directory of ../share/my_app/{icons,ui} and I would look there before
    > using /(prefix) compiled in to the binary so if you drop another
    > version into a different location (e.g. during development/testing),
    > it will work in a self-consistent way.
    >
    > Another way is to have an optional environment variable to override
    > other search methods, in case that's required.


    I've used a mix of these two methods in some programs:

    * If an environment variable XXX is set, it is used as a 'seed' value
    for an internal program path variable. The environment variable can
    override the rest of the pathname initialization logic, so that one
    can still run for example

    cd src
    env XXX=/tmp/keramida/modules ./program

    * If the XXX environment variable is not used, then the program checks
    for a file called `Makefile' in the directory of the binary itself.
    The assumption that `$prefix/bin' will not have a `Makefile' seems
    to be a safe bet so far.

    * If the `Makefile' exists, I assume that the program is run from
    within its own source tree, and the pathnames are initialized to
    point in places that match the source tree layout.

    * If the `Makefile' doesn't exist, I assume that the program is
    ``installed'' so I initialize pathnames to point under `$prefix'
    instead.

    This is a bit more work that hard-coding pathnames in the source, but it
    has really paid off several times. It's very nice to be able to run a
    program both inside its own source tree *and* in an installed `form'.

    There is one point that is worth a bit of attention though:

    Having two different code paths in the executable means that when
    the program runs from within its source tree some parts of the
    source are not tested. Being able to use test runs from within the
    source- or build-tree should *not* be considered adequate testing or
    a substitute for real QA of the final program distribution.


  5. Re: what's the standard way to load resources

    On Oct 27, 5:33 pm, Jean-Marc Bourguet wrote:
    > Jarod Liu writes:


    > > I'm new to *nix environment programming. I not sure what's
    > > the correct way to load resources. For example, after
    > > installation an application's layout as below:


    > > /(prefix)/bin/my_app
    > > /(prefix)/share/my_app/icons/a.png
    > > /(prefix)/share/my_app/ui/a.glade


    > > How to write code to load a.png/a.glade correctly(the path)
    > > regardless whatever prefix choose when installation?


    > I assume the problem is finding .


    > The most robust and portable way I know to find is
    > for my_app to be a shell script which use $0 to get the path
    > to the script and then launch the executable. And that's not
    > fool proof (one problem being symbolic links... but whatever
    > methods you end up using, you'll have to define what you do
    > with symbolic links -- do you accept /share to be a
    > symbolic link? and /bin? and having launch my_app
    > through a symbolic link to /bin/my_app? I've seen
    > some people do that and then complain if it doesn't work).
    > And if my_app uses dynamic libraries in /lib, that
    > could even be the only way to launch it if you don't want
    > users to have to set up things.


    It's possible to test if the results were a symbolic link, and
    resolve it. (If someone invokes your script with ". program",
    however, you'll be lost.) If the user uses a hard link,
    however, you're screwed.

    Another possibility is to deliver your program as a package with
    a post-install script which patches the install directory name
    into the shell script. (If your application consists of several
    programs, you'll want to do this anyway.)

    > You can be less portable and use things like /proc/self/exe
    > under Linux or /proc/$$/path/a.out under Solaris which are
    > symbolic links to the executable.


    > Then you can start from argv[0] and use the fact that's
    > usually what the user typed. So if it is relative, it's to
    > the current directory. If it is a simple filename, it has
    > been searched in the PATH.


    This is probably adequate for most applications. The shells and
    the click to start icons will pass a name as if it had been
    typed, as does the cron demon an at. (At even wraps it in a
    script restoring the complete environment.) And I think inetd.
    About the only time you'll run into problems is if you're
    writing something to be used as a login shell, or if the user
    screws up in calling one of the exec functions to start you.

    --
    James Kanze (GABI Software) email:james.kanze@gmail.com
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

  6. Re: what's the standard way to load resources

    These suggestions do helpful. Thank you very much all you guys.

+ Reply to Thread