> >> >> What you should do is ask yourself:
> >> >> Q: Why do I want to know where the executable is?
> >> >> A: Because I want to do X.
> >> >> Once you have that answer, then the question is: "Since I
> >> >> _dont'_ know where my executable is, how do Unix programs
> >> >> usually do X?"
> >> >Often this is done so that you can then locate the configuration files
> >> >associated with a program by searching directories near the
> >> >executable. If the files are not around (because the program was
> >> >invoked via a symbolic link or something) it just complains that the
> >> >installation is incorrect and exits.
> >> To which point 1.14.1 of the Unix Programmer's FAQ
> >> (http://www.faqs.org/faqs/unix-faq/programmer/faq/) that I refered to says
> >> "1.14.1 So where do I put my configuration files then?
> >> -----------------------------------------------------
> >> 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').
> >> ..."
> > The argument in the FAQ is pretty weak, basically boiling down to
> > "This is considered to be bad form." Well excuuuse me!
> You're excused. Go ahead an do it if you want. It's possible
> that Unix progrmmers over the past 30 years were all wrong, and
> you're right.
Since I've been a Unix programmer for twenty five years they can't
*all* have been wrong, but...
> It is considered bad form.
> 1) That means that if you do it that way, your program won't
> work the way the rest of the system does. In the SW
> engineering classes I took the definition of a bug is "when
> a program doesn't do what a user reasonably expects it to
> do." That was the only useful thing I learned in those
> On a Unix system, a reasonable user will not exepct that
> the location of configuration files depends on the location
> of the executable. If your program does so, it is therefore
> a bug. It will cause problems for users.
Reasonable users don't care about the location of the configuration
files. They have no expectation one way or another. They expect the
application to perform the task for which it was designed.
> 2) It's considered bad form for a _reason_ (several, actually):
> a) It's a very useful thing to be able to put executable
> stuff in a read-only filesystem and share it amongst
> hosts. This precludes putting configuration data in the
> same location, since it generally needs to be both
> writable and host-specific.
It does not preclude this at all, in general if the executable is
found in a directory such as <whatever>/usr/bin/foo the program can
look in <whatever>/var/lib/foo/ for configuration files. If
<whatever> happens to be the empty string the configuration files will
be found on the writable /var filesystem.
Quote:> b) Placing configuration files in a seperate location makes
> it far easier to upgrade/reinstall the OS or program
> without loosing the configuration data.
Per-user configuration data is a separate issue, and of course belongs
in the user's home directory. We're talking about system-wide
configuration files, such as those that appear in /etc - the files
that are installed or created when the program is installed, not while
it is running.
Quote:> c) Putting all of the configuration files in known,
> predicatable locations makes it easy to take a
> "snapshot" of your system configuration without having
> to save gigabytes of executable images that you don't
> care about. IOW, you don't have to back up /usr/bin as
> often (or at all, on some systems) compared with /etc or
> the user home directories.
The relative method doesn't preclude a program from installing its
configuration files in /etc, as demonstrated by my example above.
What it does do is allow multiple versions to coexist.
Quote:> d) Historically, there's no reliable way to _find_ the
> executable's path.
This is true in theory but irrelevant in practice. If the program's
installation is screwed up to the point that it can't find its own
executable you go in and fix it, like any other bug.