Unix specifics

Under Unix you usually have two ways of redistributing your binaries. You either pack everything in a single directory, even providing Allegro in binary or source form for the user to compile. Or your program is being packaged separately from Allegro and stored in different paths. For the first case of redistribution, read section "Files shared by Allegro" from the "Dos specifics" chapter to learn more about this.

For the second type, you can ignore redistributing the setup, keyboard mappings and language datafiles, because they will be already installed in the system. This, however, is problematic if you are using get_config_text() to localise your program's text strings.

The problem is that on other platforms you usually mix your program's text strings with those of Allegro (found in the `resources' directory) to create a special language.dat. And it is likely that the Allegro library installed on the user's system already contains a datafile.dat. You can go ahead and still provide your own language.dat file, but this will mean that if Allegro is updated, your language.dat file may not contain all the text strings used by the new version.

Given the slow paced release cycle of Allegro, this might not be a concern. However, if you want to make it easy on system administrators, instead of providing your own `language.dat', you should provide the separate `xxtext.cfg' files it in a separate directory. Then, before showing the strings to the user you can detect the language setting and use override_config_file() with the appropriate localisation file and call reload_config_texts().

In order to locate things like the config and translation files, Allegro needs to know the path to your executable. Since there is no standard way to find that, it needs to capture a copy of your argv[] parameter, and it does this with some preprocessor macro trickery. Unfortunately it can't quite pull this off without a little bit of your help, so you will have to write END_OF_MAIN() right after your main() function. Pretty easy, really, and if you forget, you'll get a nice linker error about a missing _mangled_main function to remind you :-)

Under Unix resources are searched for in many different paths (see above). When a configuration resource is looked for, it is usually tried with the variations `name.cfg' or `.namerc' in multiple paths: the current directory, the directory pointed to by the ALLEGRO environment variable, the user's home directory, one or more global system directories which usually only the root user has access to and any custom paths set up with set_allegro_resource_path(). Text files, like the main allegro config file or a language text translation files are looked for in the following places: 
   ./allegro.cfg
   $ALLEGRO/allegro.cfg
   ~/allegro.cfg
   ~/.allegrorc
   /etc/allegro.cfg
   /etc/allegrorc
Binary resources like the language translation files packfile (language.dat) are looked for in: 
   ./language.dat
   $ALLEGRO/language.dat
   ~/language.dat
   /etc/language.dat
   /usr/share/allegro/language.dat
   /usr/local/share/allegro/language.dat
Note that if you have installed Allegro from the source distribution with the typical `make install', global files like `language.dat' and `allegro.cfg' will not have been installed. As a system administrator you are required to install them manually wherever you prefer to have them. If you suspect that an Allegro program is somehow not finding the correct configuration file, you could try using the following command: 
   strace program 2>&1|egrep "(open|stat)"
The strace program traces system calls and signals. By default it outputs the information to stderr, so that's why we redirect it to stdin with `2>&1'. Since we are interested only in files being (un)successfully opened, we restrict the output of the log to stat or open calls with the extended grep command. You could add another grep to filter only lines with text like `language' or `allegro'.

Unix integration routines