> > Within a 'c' program I need to know the directory from which the program was
> > run.
> This is a meaningless concept. And a FAQ. Files are associated with
> inodes, not with directories. Thus hard links. The file may exist in
> multiple locations, or noplace at all!
If your system has /proc/self/cwd, then this can be used to determine the
the processes current working directory, try man proc(5). Here is a snippet
cwd This is a link current working directory of the
process. To find out the cwd of process 20, for
instance, you can do this:
cd /proc/20/cwd; /bin/pwd
Note that the pwd command is often a shell builtin, and
might not work properly in this context.
exe a pointer to the binary which was executed, and
appears as a symbolic link. readlink(2) on the exe
special file returns a string in the format:
For example, :1502 would be inode 1502 on
device major 03 (IDE, MFM, etc. drives) minor 01
(first partition on the first drive).
Also, the symbolic link can be dereferenced normally
- attempting to open "exe" will open the executable.
You can even type /proc/[number]/exe to run another
copy of the same process as [number].
find(1) with the -inum option can be used to locate
A process can change its cwd, but if you write the program then you
know if it will or not, most programs typically do not. If it is the cwd
you want, then be aware that if a program is started from anything other
than a shell, it may not be what you expect.
Also an executable can be removed after it is run, so the dereference
may not work. Again this is a unlikely occurence, typically one
can handle that case gracefully. But this probably isn't what you want
to do, as the following suggests. Also the stuff above is Linux only.
Quote:> > I want to have a configuration file located in this directory with default
> > options etc.
If it's an X application there is /usr/X11/lib/app-defaults, or something
similar(It is configurable). All X11 applications can get resources from
that directory as well as a number of other locations.
> Ah, another DOS programmer tries to make the move to UNIX/Linux.
> Even if it were possible to do what you ask (which it's not, but
> half-assed solutions can be hacked up), it would be wrong, because
> BINARY FILES SHOULD NOT BE IN THE SAME DIRECTORY AS CONFIG FILES.
> Config files may be shared across a network of heterogenous machines.
> Binaries obviously cannot be.
> The standard way of dealing with this in the UNIX world is to specify
> a set of standard locations for config files, along with an override
> option, usually through an environment variable.
> > It can't be centrally located because there may be more than
> > one copy on the machine.
> I don't understand this statement. It must be centrally located
> because there may be more than one copy on more than one machine.
> If you want to have multiple configurations on one machine (and/or
> net), the most common way to do that is to have locations relative to
> the user's home directory in the list of standard places that config
> files are searched for.
> Thus: you might have a search order like:
> $MY_PROGRAMS_CONFIG # absolute override env. variable
> ~/.my_program/ # user's default override location
> /etc/my_program # one systemwide default
> /opt/myprogram/etc # another possible systemwide default
> /usr/share/myprogram # " " " "
> /usr/local/share/myprogram # " " " "
> The overrides with environment variables, and with the user's home
> directory should provide all the flexibility you could ask for.
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.