Walter Bright wrote:
> Frank Benoit wrote:
>>> I see, that explains why it worked for me (I used direct path names).
>>
>> The "executable" name can also be a symbolic link.
>>
>> ln -s /home/frank/dmd/bin/dmd ./lnk
>> ./lnk
>>
>>
>> Arg 0 show up with "./lnk". So it is necessary to follow those symbolic
>> links.
> 
> I'm rather unfamiliar with that, any snippet of code available?

In the case of creating a symlink to dmd (or any other application), I'd suggest that the directory of the link be used in preference to the location of the other end of the link.  Add another check ahead of the binaries location:

...
# check directory with argv0
if [ -e dirname($argv0)/dmd.conf ]; then
    return dirname($argv0)/dmd.conf;
# check directory of the source of the link, if it is a link
elif [ -l $argv0 && -e dirname(readlink($argv0))/dmd.conf ]; then
    return dirname(readlink($argv0));
# continue with other checks...
elif ...

Sorry for the pseudo shell code, but the equivalent c code isn't much different.

Sean Kelly wrote:
> 
> I was being lazy and trying to avoid starting my Linux VM :-)  But I just wrote an app like the above, compiled it as "app", moved the executable to /dmd/bin, and ran it.  As suspected, argv[0] was "app" and not "/dmd/bin/app" as the DMD front-end seems to expect.  I also couldn't find a built-in way to determine the location of the executing process, so it may be that DMD will have to iterate across the PATH list as Build does.
> 
> 
> Sean

When argv[0] isn't an absolute path, then isn't the location of the executing process file =  CWD ~ argv[0] ?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Sean Kelly wrote:
> 
>>
>> I was being lazy and trying to avoid starting my Linux VM :-)  But I just wrote an app like the above, compiled it as "app", moved the executable to /dmd/bin, and ran it.  As suspected, argv[0] was "app" and not "/dmd/bin/app" as the DMD front-end seems to expect.  I also couldn't find a built-in way to determine the location of the executing process, so it may be that DMD will have to iterate across the PATH list as Build does.
>>
>>
>> Sean
> 
> 
> When argv[0] isn't an absolute path, then isn't the location of the executing process file =  CWD ~ argv[0] ?
> 

You will also have to search the path to find it. argv[0] seems to be whatever you used to call the program put something on the path and run it without a full path you will get the name you typed in


<code name="test.d">
import std.stdio;
void main(char[][] argv){foreach(i,a;argv)writef("%d:>\"%s\"\n",i,a);}
</code>

// put in path at /bin/foo/
$test
0:>"test"

// call directly
$/bin/foo/test
0:>"/bin/foo/test"

// call locally
$./test
0:>"./test"

Seems to be a direct mapping to whater exec was given.

BCS wrote:
> Bruno Medeiros wrote:
>> Sean Kelly wrote:
>>
>>>
>>> I was being lazy and trying to avoid starting my Linux VM :-)  But I just wrote an app like the above, compiled it as "app", moved the executable to /dmd/bin, and ran it.  As suspected, argv[0] was "app" and not "/dmd/bin/app" as the DMD front-end seems to expect.  I also couldn't find a built-in way to determine the location of the executing process, so it may be that DMD will have to iterate across the PATH list as Build does.
>>>
>>>
>>> Sean
>>
>>
>> When argv[0] isn't an absolute path, then isn't the location of the executing process file =  CWD ~ argv[0] ?
>>
> 
> You will also have to search the path to find it. argv[0] seems to be whatever you used to call the program put something on the path and run it without a full path you will get the name you typed in
> 
> 
> <code name="test.d">
> import std.stdio;
> void main(char[][] argv){foreach(i,a;argv)writef("%d:>\"%s\"\n",i,a);}
> </code>
> 
> // put in path at /bin/foo/
> $test
> 0:>"test"
> 
> // call directly
> $/bin/foo/test
> 0:>"/bin/foo/test"
> 
> // call locally
> $./test
> 0:>"./test"
> 
> Seems to be a direct mapping to whater exec was given.

Agh, of course, that was silly of me. :Z

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

http://d.puremagic.com/issues/show_bug.cgi?id=278


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #4 from bugzilla@digitalmars.com  2006-08-11 19:18 -------
Fixed DMD 0.164


-- 

Walter Bright schrieb am 2006-08-05:
> Frank Benoit wrote:
>>> I see, that explains why it worked for me (I used direct path names).
>> 
>> The "executable" name can also be a symbolic link.
>> 
>> ln -s /home/frank/dmd/bin/dmd ./lnk
>> ./lnk
>> 
>> 
>> Arg 0 show up with "./lnk". So it is necessary to follow those symbolic links.
>
> I'm rather unfamiliar with that, any snippet of code available?


| #include <stdlib.h>
| #include <stdio.h>
| #include <errno.h>
| #include <unistd.h>
|
| #if defined(__GLIBC__)
| #define realPath(a) realpath((a), NULL)
| #else
| char* realPath(char* path){
|     /* 4.4BSD, POSIX.1-2001 */
|     char* buf = NULL;
|     char* abs_path = NULL;
|
|     #if defined(PATH_MAX)
|         #define len PATH_MAX
|     #else
|         ssize_t len;
|         len = pathconf(path, _PC_PATH_MAX);
|         if (len <= 0){
|             len = 4096;
|         }
|     #endif
|
|     buf = calloc(len, 1);
|     abs_path = realpath(path, buf);
|     errno = 0;
|
|     return abs_path ? abs_path : path;
| }
| #endif
|
| int main(int argc, char* argv[]){
|     printf("argv:\t%s\n", argv[0]);
|     printf("real:\t%s\n", realPath(argv[0]));
|
|     return 0;
| }

Thomas

http://d.puremagic.com/issues/show_bug.cgi?id=278


thomas-dloop@kuehne.cn changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
           Keywords|                            |patch
         Resolution|FIXED                       |




------- Comment #6 from thomas-dloop@kuehne.cn  2006-09-21 01:16 -------
The current (dmd-0.167) search strategy is incorrect.

sample:
/opt/dmd/bin/dmd
/opt/dmd/bin/dmd.conf
/usr/bin/dmd -> /opt/dmd/bin/dmd (symlink)

PATH=/usr/bin/:/usr/local/bin/
HOME=/home/user
CWD=/home/user/project

dmd-0.167 is looking for dmd.conf in the following places:
[1] /home/user/project/dmd.conf (CWD)
[2] /home/user/dmd.conf (HOME)
[3] /usr/bin/dmd.conf (argv0)
[4] /usr/bin/local/dmd.conf (argv0)
[5] /etc/dmd.conf (/etc)

The problem is that [3] and [4] are using PATH instead of argv0.

dmd should - according to the documentation - look for dmd.conf in the
following places:
[1] /home/user/project/dmd.conf (CWD)
[2] /home/user/dmd.conf (HOME)
[3] /opt/dmd/bin/dmd.conf (argv0)
[4] /etc/dmd.conf (/etc)

See http://d.puremagic.com/issues/show_bug.cgi?id=278#c5 for a fix.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=278





------- Comment #7 from thomas-dloop@kuehne.cn  2006-10-14 11:02 -------
Created an attachment (id=38)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=38&action=view)
fixed inifile.c


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=278





------- Comment #8 from digitalmars-com@baysmith.com  2006-10-28 18:07 -------
I ran into this today. Since a fix is attached, any chance this will be included in the next release?


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=278


andrei@metalanguage.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@metalanguage.com
           Severity|normal                      |regression




------- Comment #9 from andrei@metalanguage.com  2007-10-06 23:01 -------
In dmd 2.005 on ubuntu, dmd.conf is not inspected whether it's in $HOME or the same place as the dmd executable.


--