| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This would be a good candidate for a list of `Frequently Unanswered Questions', because the fact of asking the question usually means that the design of the program is flawed. :-)
You can make a `best guess' by looking at the value of argv[0].
If this contains a ‘/’, then it is probably the absolute or
relative (to the current directory at program start) path of the
executable. If it does not, then you can mimic the shell's search of
the PATH variable, looking for the program. However, success is
not guaranteed, since it is possible to invoke programs with arbitrary
values of argv[0], and in any case the executable may have been
renamed or deleted since it was started.
If all you want is to be able to print an appropriate invocation name
with error messages, then the best approach is to have main()
save the value of argv[0] in a global variable for use by the
entire program. While there is no guarantee whatsoever that the value
in argv[0] will be meaningful, it is the best option available in
most circumstances.
The most common reason people ask this question is in order to locate configuration files with their program. This is considered to be bad form; directories containing executables should contain nothing except executables, and administrative requirements often make it desirable for configuration files to be located on different filesystems to executables.
A less common, but more legitimate, reason to do this is to allow the
program to call exec() on itself; this is a method used
(e.g. by some versions of sendmail) to completely reinitialise
the process (e.g. if a daemon receives a SIGHUP).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The correct directory for this usually depends on the particular flavour
of Unix you're using; ‘/var/opt/PACKAGE’, ‘/usr/local/lib’,
‘/usr/local/etc’, or any of several other possibilities.
User-specific configuration files are usually hidden `dotfiles' under
$HOME (e.g. ‘$HOME/.exrc’).
From the point of view of a package that is expected to be usable across a range of systems, this usually implies that the location of any sitewide configuration files will be a compiled-in default, possibly using a ‘--prefix’ option on a configure script (Autoconf scripts do this). You might wish to allow this to be overridden at runtime by an environment variable. (If you're not using a configure script, then put the default in the Makefile as a ‘-D’ option on compiles, or put it in a ‘config.h’ header file, or something similar.)
User-specific configuration should be either a single dotfile under
$HOME, or, if you need multiple files, a dot-subdirectory.
(Files or directories whose names start with a dot are omitted from
directory listings by default.) Avoid creating multiple entries under
$HOME, because this can get very cluttered. Again, you can allow
the user to override this location with an environment
variable. Programs should always behave sensibly if they fail to find
any per-user configuration.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
This document was generated on September, 10 2007 using texi2html 1.77.