[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Hi
I'm not sure if this has come up before, I'm a bit out of date
now and still don't have 3.9.26. It's an idea about the
conflict between the way DOS/Windows applications tend to work
and the way Linux applications work, regarding the storing of
data files.
DOS and Windows applications tend to use the directory
containing the executable, and subdirectories of that directory.
That works OK in those systems, because (a) it's either easy to
find out what that directory is, or it tends to be the current
directory, and (b) a program's executables tend to live grouped
together in a separate directory for that program.
Under Linux, or Unix in general, it's not normal for
applications to work in that way. Unless a binary's directory
is in the search path, you must specify the path even if it's
the current directory (just `./'). Most applications install
their binaries into directories in the search path, and have
their data files in places like /usr[/local]/share/progname.
Data files that might need writing (high score tables, for
example) go in /var/... instead.
I thought it might be good to add a function to return a
directory for reading data files and possibly a different one
for reading writable files (subject to permissions still, of
course). Under DOS these would return the executable's
directory, maybe, or failing that the current directory (e.g. if
argv[0] has no path). Under Unix they'd return
/usr/share/progname, filling in `progname' using a parameter I
expect.
I thought of this while I was installing one of my games so that
other users than my own could use it; there is a fairly
reasonable way to avoid most of the problem though -- put the
game (binary and [read-only] data) in a subdirectory of
/usr[/local]/games, like in DOS, and put in /usr[/local]/bin a
simple script:
#!/bin/sh
cd /usr[/local]/games/progname
./progname
The only problem now is what to do with the variable data; there
are only mild problems with putting it in with the static data.
You can use a subdirectory that's writable by everybody in group
`games' (the group's needed for the Red Hat supplied games too);
this is totally portable to a DOS version of the game. If you
care about not writing to /usr/... much, you can make this a
symbolic link to /var/something.
So, what I suggested isn't needed -- but it's easy to implement,
and small. What do people think?
George