To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Path:	mantis!not-for-mail
From:	olly AT mantis DOT co DOT uk (Olly Betts)
Newsgroups:	mail.djgpp
Subject:	Re: Getting a path in argv[0]
Date:	2 Dec 1994 12:40:43 -0000
Organization:	Mantis Consultants Ltd, Cambridge, UK
Lines:	53
References:	<3bklfv$nth AT sunforest DOT mantis DOT co DOT uk> <199412020056 DOT SAA14699 AT saucer DOT cc DOT umr DOT edu>

In article <199412020056 DOT SAA14699 AT saucer DOT cc DOT umr DOT edu>,
Mike Castle <mcastle AT umr DOT edu> wrote:
>Amazingly enough Olly Betts said:
>> 
>> DJGPP seems to just give the leaf-name of the executable in argv[0],
>> rather than the executable path as DOS compilers seem to.  I suppose
>> this follows the UNIX style, but I have a program which uses the path
>> on argv[0] to find support files.
>
>Acutally, how this is done depends on the shell one is using in
>unix.  If familiar with the exec(2), command, you know that the
>first parm is the path to the executable, and that you can fill
>in argv[0] with anything you want.  I believe bourne shell, et al
>fill in with just the name of the executable, while csh, and
>family, use the complete path.   Actually, I've been meaning to
>check with a few other dos compilers how this works as well...

I've just tried it with all the Unix shells we have here (sh, csh, tcsh,
ksh) and they all seem to give the path.

I think I've now realised what's up.  Here's the explanation.  I'm sorry
for any confusion caused, and hope this helps someone else:

I misremembered the precise problem with UNIX.  What you get (in the
cases I've tried) is the path which was *typed* rather than the one used
to find the executable (which is what DOS compilers give you).

So if your program is ~/bin/foo, then running it with foo gives argv[0]
as "foo".  An MS DOS program in C:\BIN\FOO.EXE run with foo would get
"C:\BIN\FOO.EXE" in argv[0].

Now DJGPP actually behaves in the DOS manner, except the path passed in
argv[0] gets the slashs flipped and the name lower-cased, so you get
"c:/bin/foo.exe".  However, the code to check for a path was looking for
\ as the path separator, and so returning an empty path.

>At anyrate, the portable solution is to manully check the path().
>
>I remember when I played around with the DLD package, it had a
>routine for checking the path to do just this.  I just had to
>modify it slightly to use ; as path separators rather than ;.
>Check out prep.ai.mit.edu in pub/gnu/dld323.tar.gz (or some
>similar name).

I'll take a look at that.  It'd be useful for the UNIX version not
to need an environmental variable set.

BTW, thanks are due to Stephen Turnbull for pointing out that sed knows
its path, which made me realise that I had missed something.

Olly
-- 
If you're not part of the solution, you're part of the precipitate.

- Raw text -