I''ve written quite a few programs in Linux, but they have all been simplistic tool apps for school. I''ve never written a "large" program that can justify an installation and I''m having trouble figuring out how this works. Unix programs are spread out into at least three directories: a bin directory storing the executable, the installation directory, and the user''s home directory (usually in a hidden sub-directory). None of these directories is usually the current working directory, so how would one''s program find its global data and user settings (stored in the install directory and the user''s home directory). The best I can figure is to hard code them. But some games (Heretic 2 comes to mind) come with source code and still allow the end user to specify where to install the program. Finding the home directory would probably not be much more than a call to

const char* homedir = getenv ("HOME");
 

But I don''t know how portable (to other UNIX systems) that is. And I don''t have any idea how to find the installation directory without a brute-force filesystem search. Except, maybe, find the user''s home directory and see if there is a config file locating it for you. But that assumes there is a config file in the user''s home directory. Am I on the right track? Thanks for your help.

I''m too lazy to answer your entire post right now, but to get the user''s home directory you can do this:

struct passwd *PassWD;PassWD = getpwuid(geteuid());/* PassWD->pw_dir is now the current user''s home directory */ 

quote:
(snipped)

None of these directories is usually the current working directory, so how would one''s program find its global data and user settings (stored in the install directory and the user''s home directory). The best I can figure is to hard code them. But some games (Heretic 2 comes to mind) come with source code and still allow the end user to specify where to install the program.

Usually my programs do this:

- load hardcoded default settings,
- check if the host wide config exists (more later). If so, load it and override hardcoded settings,
- check if $HOME/.program_namerc exists, if so load it and override global settings.

It means that I have to hardcode sensible settings that will provide at least minimal functionalities. As long as it runs, the user will be able to configure it.

Keep in mind that all the programs I''ve written were installed from source. There is a somewhat tricky part here: when using the GNU autotools (and some other "build process" tools), the user has the possibility to specify destinations (e.g.: --prefix=/usr/local and/or --bindir=/usr/local/bin). This can sometimes lead to problems.

In order to manage this, my configure scripts generate 1) the default global configuration and 2) a header file that will hold the said hardcoded values. Assuming that configure was executed with --prefix=/usr/local, --bindir=/usr/local/foo/bin and --config=/home/foo/.something, the configuration file would look like this:

root_dir=/usr/local
bin_dir=/usr/local/foo/bin

and the header would contain something like:

#define GLOBAL_CONFIG "/home/foo/.something"
#define DEFAULT_PERMISSION 0740

The "GLOBAL_CONFIG" will be compiled in, and the program will try to find that file. The "DEFAULT_PERMISSION" (as well as other defined values) will serve as a base in case no configuration file is found.

This is maybe overkill. A lot of programs will simply require that root runs the install and put their configuration files(s) under /etc. I simply don''t like to assume too much about a user''s privileges etc.

If you''re using some kind of graphical installer for a binary distribution (like the Loki installer), you''ll probably have to require that the user be root, in order to perform a host/site wide installation.

quote:
Finding the home directory would probably not be much more than a call to

const char* homedir = getenv ("HOME";

A user could export another "HOME" and totally screw it up. Of course, such users deserve it .

quote:
But I don''t know how portable (to other UNIX systems) that is.

getenv is ISO9899 and POSIX (and also SVID 4 and BSD4.3 according to the man page). I know of no UNIX-like system that doesn''t implement it (it wouldn''t be a "UNIX" anyway as it is part of the specification). Even Windows -- at least NT -- has a _getenv in its POSIX layer, and it might also have a getenv.

Finally, the FHS is the reference if you''re wondering "where should that go?". See http://www.pathname.com/fhs for more infos.

Hope this helps.

glibc supplys methods for reading /etc/passwd for thingsl ike getting user''s "real name", homedir, etc. I think anon already had that, not sure. too lazy to check

beyond that The usual installations methods:

REALLY important / (/etc /bin blah blah blah)
Usual applications /usr
Usual applications /usr/local

what difference does the local make? Well, by tradition /usr is mounted from an NFS share on a master server (change one machine & everybody is updated) and /usr/local is the equivalent only for the local machine.

Last I checked, a lot linux distributions are evil and forget why /usr/local is there

One more reason I love freebsd (huge problem, love freebsd''s userspace, linux''s kernel. Go figure)

Thanks all for the information. Let me digest that for a while and see what I can''t come up with.