Bug 278 – dmd.conf search path doesn't work

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.

Walter Bright wrote: > BCS wrote: >> Walter Bright wrote: >>> [email protected] 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

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

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.

Fixed DMD 0.164

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- iD8DBQFFEc1cLK5blCcjpWoRAqe3AJ9yGXBkluauZjtHmBbroFg+3Ryx5wCglLTF 3gpxOtilRfYAdUxXsqH4idc= =94mR -----END PGP SIGNATURE-----

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.

Created attachment 38 fixed inifile.c

I ran into this today. Since a fix is attached, any chance this will be included in the next release?

In dmd 2.005 on ubuntu, dmd.conf is not inspected whether it's in $HOME or the same place as the dmd executable.

1.022 can't find dmd.conf in the bin directory if it's called using PATH, whereas it 1.021 and 1.015 could find it. ==== [ 1.021 ] ==== export PATH="...:/home/dphillips/opt/dmd-1.021/bin" strace -o out dmd -ofdpc dpc.d execve("/home/dphillips/opt/dmd-1.021/bin/dmd", ["dmd", "-ofdpc", "dpc.d"], [/* 66 vars */]) = 0 ... stat64("dmd.conf", 0xbfc2ebec) = -1 ENOENT (No such file or directory) stat64("/home/dphillips/dmd.conf", 0xbfc2ebec) = -1 ENOENT (No such file or directory) stat64("dmd.conf", 0xbfc2ebec) = -1 ENOENT (No such file or directory) stat64("/home/dphillips/bin/dmd", 0xbfc2ebbc) = -1 ENOENT (No such file or directory) stat64("/usr/local/bin/dmd", 0xbfc2ebbc) = -1 ENOENT (No such file or directory) stat64("/usr/bin/dmd", 0xbfc2ebbc) = -1 ENOENT (No such file or directory) stat64("/usr/X11R6/bin/dmd", 0xbfc2ebbc) = -1 ENOENT (No such file or directory) stat64("/bin/dmd", 0xbfc2ebbc) = -1 ENOENT (No such file or directory) stat64("/usr/games/dmd", 0xbfc2ebbc) = -1 ENOENT (No such file or directory) stat64("/opt/gnome/bin/dmd", 0xbfc2ebbc) = -1 ENOENT (No such file or directory) stat64("/usr/lib/mit/bin/dmd", 0xbfc2ebbc) = -1 ENOENT (No such file or directory) stat64("/usr/lib/mit/sbin/dmd", 0xbfc2ebbc) = -1 ENOENT (No such file or directory) stat64("/home/dphillips/opt/git/bin/dmd", 0xbfc2ebbc) = -1 ENOENT (No such file or directory) stat64("/home/dphillips/opt/git/bin/dmd", 0xbfc2ebbc) = -1 ENOENT (No such file or directory) stat64("/home/dphillips/opt/dmd-1.021/bin/dmd", {st_mode=S_IFREG|0764, st_size=1030436, ...}) = 0 stat64("/home/dphillips/opt/dmd-1.021/bin/dmd.conf", {st_mode=S_IFREG|0664, st_size=64, ...}) = 0 open("/home/dphillips/opt/dmd-1.021/bin/dmd.conf", O_RDONLY) = 3 ==== [ 1.022 ] ==== export PATH="...:/home/dphillips/opt/dmd-1.022/bin" strace -o out dmd -ofdpc dpc.d execve("/home/dphillips/opt/dmd-1.022/bin/dmd", ["dmd", "-ofdpc", "dpc.d"], [/* 66 vars */]) = 0 ... stat64("dmd.conf", 0xbff37eec) = -1 ENOENT (No such file or directory) stat64("/home/dphillips/dmd.conf", 0xbff37eec) = -1 ENOENT (No such file or directory) stat64("dmd.conf", 0xbff37eec) = -1 ENOENT (No such file or directory) getcwd("/home/dphillips/dpc", 4096) = 20 lstat64("/home/dphillips/dpc/dmd", 0xbff37f6c) = -1 ENOENT (No such file or directory) open("/etc/dmd.conf", O_RDONLY) = -1 ENOENT (No such file or directory) unlink("dpc.o") = 0

This bug was introduced and then fixed within a few hours of the release. The 1.022 and 2.005 zip files were updated to contain the fix without a new release and without an announcement. Marking this bug fixed. Please re-download if you were unlucky enough to get the buggy version. The corrected 2.005 shows version 2.005.1 in the output of just 'dmd'. The 1.022 version doesn't identify itself differently (whoops, bad Walter). The 1.002 version can be identified by, well, it working correctly, and: filesize md5sum dmd 1015780 4ffc48d69a3687339720adc4ef9f5c03 dmd.exe 1068060 2ce1fb3f5f9e65aa457622136efb9d2c

-[ /root/dmd/bin/dmd.conf ]------------------------ [Environment] DFLAGS=-I%@P%/../src/phobos -L-L%@P%/../lib --------------------------------------------------- #echo $PATH /root/dmd/bin:/root/dmd/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin #which dmd /root/dmd/bin/dmd #cat /etc/dmd.conf file not found #cd /root #dmd test.d object.d: module object cannot read file 'object.d' #md5sum dmd.1.022.zip 645b4527ae4137d0e1dc639d2cf70974 dmd.1.022.zip

If this is fixed, it should be closed.

I'm closing this bug. Please re-open with specifics if there's still a problem that anyone can find with config file locating. If you have a problem, please give details about: 1) where you have dmd.conf/sc.ini files 2) where you have dmd executables 3) what your PATH env var is set to 4) exactly how you executed dmd 5) which conf file was used in case you suggest that it should have used a different one Thanks, Brad