Very Computer

Within a 'c' program I need to know the directory from which the program was
run.  How is this done?  argv[0] seems to have only the user entered
portion.

I want to have a configuration file located in this directory with default
options etc.  It can't be centrally located because there may be more than
one copy on the machine.

--
Bryan White
ArcaMax
www.arcamax.com
Madness is a sign of the times.
You must learn to embrace it,
let it inspire you.

Quote:> Within a 'c' program I need to know the directory from which the program was
> run.  How is this done?  argv[0] seems to have only the user entered
> portion.

> I want to have a configuration file located in this directory with default
> options etc.  It can't be centrally located because there may be more than
> one copy on the machine.

  There's no way guaranteed to work. You can do the following which works
almost all of the time:

  Look at argv[0]. If it contains a / in it, then that's your path.
  If it doesn't, loop thru $PATH looking for an executable by the name of
argv[0] that has all of the appropriate modes. First one you find is your
path.

  Whatever you do, allow the user to specify the directory on the command
line. Or you can use the value of an environment variable for the directory if
it's set. If not, then do the $PATH search stuff.

  Mike McDonald

BW> Within a 'c' program I need to know the directory from which the
BW> program was run.  How is this done?  argv[0] seems to have only
BW> the user entered portion.
BW>
BW> I want to have a configuration file located in this directory with
BW> default options etc.  It can't be centrally located because there
BW> may be more than one copy on the machine.

So, the Right Way to do this is to make the location of the
configuration file a compile-time option.  Using Autoconf, you can
specify where the program will be installed with the --prefix option
to configure, and find the configuration file relative to that.  All
kinds of things (hard/symbolic links, shell-local $PATHs, rogue
programs doing weird things with the exec() call) can keep you from
finding your binary.

Another possibly more workable option for you is to use an environment
variable; if getenv("MY_CONFIG_FILE") returns something, the
configuration file should be located there, otherwise provide a
sensible default.

--
 _____________________________
/                             \       "Dad was reading a book called
|          David Maze         |     _Schroedinger's Kittens_.  A*

| http://www.veryComputer.com/|               -- Abra Mitchell
\_____________________________/

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!

Quote:> I want to have a configuration file located in this directory with default
> options etc.

Ah, another DOS programmer tries to make the move to UNIX/Linux.
Welcome.

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.

Quote:> 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.
--
Chris Waters             |


www.dsp.net/xtifr/ (web) |

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:

                     [device]:inode

                     For example, [0301]: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
                     the file.

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.  

Quote:

> Ah, another DOS programmer tries to make the move to UNIX/Linux.
> Welcome.

> 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.

  getcwd() and getwd() are better.

  Mike McDonald

I'm not sure I caught the original post, so I may be going off on a
tangent...
however, it seems to me that the original poster did not distinguish
between
application specific configuration (such as XF86Config for X), and user
configuration (which is probably best placed either in $HOME or some
subdirectory of $HOME).

If the config is for all executing instances of the app, then the
autoconf/default
location/etc. solution is appropriate. If the config is different for each
instance,
then the $HOME solution is appropriate ($HOME of the user executing the
app,
obviously 8).

I just hope I haven't missed/misread the part of the original post which
specified
which it was...

        -Duncan

just do it the way your shell does. the shell looks for the binary images
using the $PATH variable. it loops through all elements of $PATH :
it looks the contents of the directory and if it finds an executable file
with that name, it executes that file. if you do it that way, it will work.

****************************************************************************

YetGraduate Computer Science Student in Bilkent/Turkey
****************************************************************************

On Mon, 30 Nov 1998 15:53:15 +0200, Sukru Cinar

Don't think so; the executable may not be in $PATH in the first place
and/or may be deleted.

--
Gyelt Tuinstra

Please reread his original question:  he didn't ask where the
executable resides, he asked where it was run from.  The first is a
FAQ (answer:  there is no reasonable way to do that; you can try
kludges like the ones described above), while the answer to his
question is the getcwd() C library call.
--
Joseph J. Pfeiffer, Jr., Ph.D.       Phone -- (505) 646-1605
Department of Computer Science       FAX   -- (505) 646-1002
New Mexico State University          http://www.cs.nmsu.edu/~pfeiffer

If it's not in the PATH, then it's in argv[0].  Either you specify
exactly where the program is, or it's in the PATH (./program can be
located with cwd).

Whether the program is deleted makes no difference.  You can still find
out where the program WAS when it was executed.

I know that, but I was responding to Gyelt Tuinstra who commented that
"the executable may not be in $PATH in the first place and/or may be
deleted."  If I was replying to the original question, I would have
replyed to the original question!  Now, yes I agree that there is no
definative way of determining where the executable really "is" due to
symbolic links, but you can certainly tell the directory in which it was
"loaded" from.  It is either explicitly specified in argv[0] or it is in
the PATH.  I don't think there are any other possibilities, are there?
If you provide the environment with the PATH changed, does the execve
use the current PATH or the one specified to search for the executable?
This would be the only gotcha as far as I see it.

Fred

Quote:Fred writes:
> Now, yes I agree that there is no definative way of determining where the
> executable really "is" due to symbolic links, but you can certainly tell
> the directory in which it was "loaded" from.  It is either explicitly
> specified in argv[0] or it is in the PATH.  I don't think there are any
> other possibilities, are there?

Yes.  From man execve:

       int  execve  (const  char  *filename, char *const argv [],
       char *const envp[]);

Thus argv[0] is whatever you want it to be.  Your shell is kind enough to
always set argv[0] to the real name, but all programs don't.  Cron, for
example,  upcases its children.

Quote:> If you provide the environment with the PATH changed, does the execve use
> the current PATH or the one specified to search for the executable?

It is running in the current context.  
--
John Hasler

Dancing Horse Hill
Elmwood, WI

Quote:> I know that, but I was responding to Gyelt Tuinstra who commented that
> "the executable may not be in $PATH in the first place and/or may be
> deleted."  If I was replying to the original question, I would have
> replyed to the original question!

I wasn't responding so much directly to you, as to the whole series of
responses, none of which had anything to do with the question.
--
Joseph J. Pfeiffer, Jr., Ph.D.       Phone -- (505) 646-1605
Department of Computer Science       FAX   -- (505) 646-1002
New Mexico State University          http://www.cs.nmsu.edu/~pfeiffer

Just run basename(const char *); it comes with glibc 2.x.

---
  Preston Brown          
  Red Hat Software, Inc.