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

           Summary: dmd.conf search path dosn't work
           Product: D
           Version: 0.163
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: shro8822@uidaho.edu


from http://www.digitalmars.com/d/dcompiler.html

"dmd will look for the initialization file dmd.conf in the following sequence of directories:

   1. current working directory
   2. directory specified by the HOME environment variable
   3. directory dmd resides in
   4. /etc/"

However, on Linux, step number three ("directory dmd resides in") doesn't work. If /etc/dmd.conf is unreadable, dmd wont find /bin/dmd (assuming /bin/dmd is being called). This also fails if dmd is run by way of a softlink, /bin/sub/dmd.conf isn't found when the softlink /bin/sub/dmd is run. I haven't tested this on windows.

This is a killer for having several setups for dmd. Say I want dmd.163 and dmd.160 on the same box. If this worked, I could install dmd.163 in /bin with it's dmd.conf and also place a dmd.160 in /bin/160 with a dmd.conf that points to the correct phobos imports and libs.

This must be fixed before 1.0 because it would prevent dmd 1.0 and dmd 2.0 from coexisting on the same box. This is blocking a project I am working on right now so I would lick to see it fixed ASA Practical.


-- 

d-bugmail@puremagic.com wrote:
> from http://www.digitalmars.com/d/dcompiler.html
> 
> "dmd will look for the initialization file dmd.conf in the following sequence
> of directories:
> 
>    1. current working directory
>    2. directory specified by the HOME environment variable
>    3. directory dmd resides in
>    4. /etc/"
> 
> However, on Linux, step number three ("directory dmd resides in") doesn't work.

That's very strange, because that's the way I use dmd on Linux.

Walter Bright wrote:
> d-bugmail@puremagic.com wrote:
> 
>> from http://www.digitalmars.com/d/dcompiler.html
>>
>> "dmd will look for the initialization file dmd.conf in the following sequence
>> of directories:
>>
>>    1. current working directory
>>    2. directory specified by the HOME environment variable
>>    3. directory dmd resides in
>>    4. /etc/"
>>
>> However, on Linux, step number three ("directory dmd resides in") doesn't work.
> 
> 
> That's very strange, because that's the way I use dmd on Linux.

I tried copying /etc/dmd.conf to /bin/ and renaming the /etc ver something else and DMD started complaining about not being able to find object.d

Want a log?

BCS wrote:
> Walter Bright wrote:
>> d-bugmail@puremagic.com wrote:
>>
>>> from http://www.digitalmars.com/d/dcompiler.html
>>>
>>> "dmd will look for the initialization file dmd.conf in the following sequence
>>> of directories:
>>>
>>>    1. current working directory
>>>    2. directory specified by the HOME environment variable
>>>    3. directory dmd resides in
>>>    4. /etc/"
>>>
>>> However, on Linux, step number three ("directory dmd resides in") doesn't work.
>>
>>
>> That's very strange, because that's the way I use dmd on Linux.
> 
> I tried copying /etc/dmd.conf to /bin/ and renaming the /etc ver something else and DMD started complaining about not being able to find object.d
> 
> Want a log?

No. I'll recheck the source code. (You can as well!)

Walter Bright wrote:
> BCS wrote:
>> Walter Bright wrote:
>>> d-bugmail@puremagic.com wrote:
>>>
>>>> from http://www.digitalmars.com/d/dcompiler.html
>>>>
>>>> "dmd will look for the initialization file dmd.conf in the following sequence
>>>> of directories:
>>>>
>>>>    1. current working directory
>>>>    2. directory specified by the HOME environment variable
>>>>    3. directory dmd resides in
>>>>    4. /etc/"
>>>>
>>>> However, on Linux, step number three ("directory dmd resides in") doesn't work.
>>>
>>>
>>> That's very strange, because that's the way I use dmd on Linux.
>>
>> I tried copying /etc/dmd.conf to /bin/ and renaming the /etc ver something else and DMD started complaining about not being able to find object.d
>>
>> Want a log?
> 
> No. I'll recheck the source code. (You can as well!)

I do all my switching in /etc/dmd.conf and recently had some weird problems when I tried using Build on Linux.  It turned out that I had an old dmd.conf file in /dmd/bin as well, and removing this fixed things. So I think the checking of /bin/dmd/dmd.conf may not work correctly.  I have /dmd/bin in my path, could it be that the argv[0] doesn't contain a fully qualified path name and so the function ends up looking in the current directory twice?


Sean

Sean Kelly wrote:
> I do all my switching in /etc/dmd.conf and recently had some weird problems when I tried using Build on Linux.  It turned out that I had an old dmd.conf file in /dmd/bin as well, and removing this fixed things. So I think the checking of /bin/dmd/dmd.conf may not work correctly.  I have /dmd/bin in my path, could it be that the argv[0] doesn't contain a fully qualified path name and so the function ends up looking in the current directory twice?

Easy enough to check, compile/run this program on your system:


> #include        <stdio.h>
> #include        <assert.h>
> #include        <stdlib.h>
> 
> int main(argc,argv)
> int argc;
> char *argv[];
> {       int i;
> 
>         printf("%d arguments\n",argc);
>         for (i = 0; i < argc; i++)
>                 printf("arg[%d] = '%s'\n",i,argv[i]);
>         assert(argv[argc] == NULL);
>         return EXIT_SUCCESS;
> }

Walter Bright wrote:
> Sean Kelly wrote:
>> I do all my switching in /etc/dmd.conf and recently had some weird problems when I tried using Build on Linux.  It turned out that I had an old dmd.conf file in /dmd/bin as well, and removing this fixed things. So I think the checking of /bin/dmd/dmd.conf may not work correctly.  I have /dmd/bin in my path, could it be that the argv[0] doesn't contain a fully qualified path name and so the function ends up looking in the current directory twice?
> 
> Easy enough to check, compile/run this program on your system:
> 
>> #include        <stdio.h>
>> #include        <assert.h>
>> #include        <stdlib.h>
>>
>> int main(argc,argv)
>> int argc;
>> char *argv[];
>> {       int i;
>>
>>         printf("%d arguments\n",argc);
>>         for (i = 0; i < argc; i++)
>>                 printf("arg[%d] = '%s'\n",i,argv[i]);
>>         assert(argv[argc] == NULL);
>>         return EXIT_SUCCESS;
>> }

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

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.

I see, that explains why it worked for me (I used direct path names).

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

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?