Re: Absolute path in argv[0]

From: Heny Townsend (henry.townsend_at_not.here)
Date: 10/30/04 

Date: Sat, 30 Oct 2004 13:19:00 GMT

Floyd L. Davidson wrote:
> Regardless, the "appropriate" place is certainly not related to
> the location of the executable.

Much of this thread has become unbecomingly dismissive but the above
statement takes the cake. Of course the appropriate place is *related*
to the location of the executable. When I install any piece of freeware,
for instance, I choose a --prefix value and then all the files are
installed relative to <prefix>. How, for instance, is
/opt/samba/lib/smb.conf not related to /opt/samba/sbin/smbd?

Just to get this out of the way first: I'm a 25-year Unix developer. My
attitudes are in no way tainted by the Windows way and in fact I'm a
charter member of the Windows-hater club. One of the things that's so
noxious about Windows is the focus on the "Personal" part of "Personal
Computer". In Windows, all installs are local installs. If you have 250
machines on your network you must install each SW package 250 times,
using 250 times as much disk space, make 250 sets of registry entries,
etc. You never know how much your C:\Windows directory may have been
polluted by DLL's silently dumped there by an install. And uninstalls
have historically at least tended to leave cruft behind.

Not to mention that one of the worst things about this model is that in
many team/workplace environments "personal" thinking is just the wrong
model. I don't want the compiler to work differently on Tom's machine
than on ***'s. I don't want to spend half a day debugging a problem
only to find out it's because the user's machine was pointing at a
different server from everyone else's. There are such things as teams
and it follows that there are such things as team conventions, aka
global settings.

One of the things that's attractive about the Unix model is that
"installs" can be so simple as to not even require the name. I can
usually install something on a Unix machine by simply unpacking a tar
file and modifying PATH and MANPATH to point into the new dir. Or I can
put, say, gcc in /usr/local/gcc[*] and NFS mount it everywhere.
Uninstalls in this model are as simple as "rm -rf".

[*] Yes, I'm aware that many people and standards have a problem with
/usr/local. I use it here only because it's the most widely recognized
example.

Of course it's not possible for every software package to be as easy as
this but it is *absolutely* a worthwhile goal. And that's all Otto is
trying to achieve. I don't think he said he wanted to put the config
file in a bin directory; he wants to *find* the bin directory so as to
traverse over to a ../etc or equivalent.

Some of the alternatives people are pushing in this thread sound
perilously close to the Windows way. Consider the problems with putting
config files in /etc: (1) you have to copy the file to every machine,
(2) there's a likelihood of configuration skew, and (3) uninstalls tend
to leave those lonely files in /etc behind. Just a month or two ago I
was burned by an old config file left behind in /etc. Ok, consider the
problems caused by compiling in the path to the config file: (1) it
works a heck of a lot better with open source than with commercial
software and not everyone is doing open source. (2) Even with OSS, it
makes it hard to package prebuilt binaries (.rpm, .deb, .pkg, etc). Of
course you can make it overridable with an EV but that just moves the
local-config burden to ~/.profile.

My own SW tool has the usual chain of config files. I let the user
specify one as an EV, I look in the cwd, I look in $HOME, I look in
/etc, and last I try to determine the path to the executable and then go
up two levels and across to an 'etc' directory and look for a config
file there. This allows per-system, per-user, or per-project settings
but it also provides a global fallback in order to set conventions for
the entire team, and there's no *need* to ever make a local setting. I
have yet to see an argument, in this thread or the Unix FAQ or
elsewhere, that convinces me this is stupid. The argument that finding
the executable is hard, non-portable, and that there are corner cases
which can't be solved comes the closest but guess what folks, it's still
not a deal breaker. For one thing I've been able to find a solution for
every platform that concerns me. For another, what's the worst thing
that could happen as the result of some trickster moving the executable
after it's run but before it locates itself? I wouldn't find the final
fallback config file. Boo hoo.

I really think people should get off their high horses here. In
particular, accusing the other side of being polluted by Windows-think
is like trying to argue that your presidential candidate has God on his
side - it could even be true but please stick to verifiable facts. 

-- 
Henry Townsend