digitalmars.D.bugs - [Issue 278] New: dmd.conf search path dosn't work
- d-bugmail puremagic.com (32/32) Aug 03 2006 http://d.puremagic.com/issues/show_bug.cgi?id=278
- Walter Bright (2/13) Aug 03 2006 That's very strange, because that's the way I use dmd on Linux.
- BCS (5/23) Aug 03 2006 I tried copying /etc/dmd.conf to /bin/ and renaming the /etc ver
- Walter Bright (2/27) Aug 04 2006 No. I'll recheck the source code. (You can as well!)
- Sean Kelly (9/37) Aug 04 2006 I do all my switching in /etc/dmd.conf and recently had some weird
- Walter Bright (2/24) Aug 04 2006
- Sean Kelly (9/35) Aug 04 2006 I was being lazy and trying to avoid starting my Linux VM :-) But I
- Walter Bright (2/9) Aug 04 2006 I see, that explains why it worked for me (I used direct path names).
- Frank Benoit (5/7) Aug 05 2006 The "executable" name can also be a symbolic link.
- Walter Bright (2/12) Aug 05 2006 I'm rather unfamiliar with that, any snippet of code available?
- Brad Roberts (16/29) Aug 05 2006 In the case of creating a symlink to dmd (or any other application), I'd...
- Thomas Kuehne (46/58) Sep 20 2006 -----BEGIN PGP SIGNED MESSAGE-----
- Bruno Medeiros (6/17) Aug 08 2006 When argv[0] isn't an absolute path, then isn't the location of the
- BCS (18/36) Aug 08 2006 You will also have to search the path to find it. argv[0] seems to be
- Bruno Medeiros (5/48) Aug 08 2006 Agh, of course, that was silly of me. :Z
- d-bugmail puremagic.com (9/9) Aug 11 2006 http://d.puremagic.com/issues/show_bug.cgi?id=278
- d-bugmail puremagic.com (31/31) Sep 20 2006 http://d.puremagic.com/issues/show_bug.cgi?id=278
- d-bugmail puremagic.com (6/6) Oct 14 2006 http://d.puremagic.com/issues/show_bug.cgi?id=278
- d-bugmail puremagic.com (5/5) Oct 28 2006 http://d.puremagic.com/issues/show_bug.cgi?id=278
- d-bugmail puremagic.com (10/10) Oct 06 2007 http://d.puremagic.com/issues/show_bug.cgi?id=278
- d-bugmail puremagic.com (59/59) Oct 08 2007 http://d.puremagic.com/issues/show_bug.cgi?id=278
- d-bugmail puremagic.com (19/19) Oct 13 2007 http://d.puremagic.com/issues/show_bug.cgi?id=278
- d-bugmail puremagic.com (23/23) Oct 13 2007 http://d.puremagic.com/issues/show_bug.cgi?id=278
- d-bugmail puremagic.com (4/4) Jun 24 2008 http://d.puremagic.com/issues/show_bug.cgi?id=278
- d-bugmail puremagic.com (22/22) Jun 07 2009 http://d.puremagic.com/issues/show_bug.cgi?id=278
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. --
Aug 03 2006
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.
Aug 03 2006
Walter Bright wrote:d-bugmail puremagic.com wrote: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?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.
Aug 03 2006
BCS wrote:Walter Bright wrote:No. I'll recheck the source code. (You can as well!)d-bugmail puremagic.com wrote: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?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.
Aug 04 2006
Walter Bright wrote:BCS 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? SeanWalter Bright wrote:No. I'll recheck the source code. (You can as well!)d-bugmail puremagic.com wrote: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?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.
Aug 04 2006
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; }
Aug 04 2006
Walter Bright 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. SeanI 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; }
Aug 04 2006
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).
Aug 04 2006
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.
Aug 05 2006
Frank Benoit wrote:I'm rather unfamiliar with that, any snippet of code available?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.
Aug 05 2006
Walter Bright wrote:Frank Benoit wrote: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: ... if [ -e dirname($argv0)/dmd.conf ]; then return dirname($argv0)/dmd.conf; elif [ -l $argv0 && -e dirname(readlink($argv0))/dmd.conf ]; then return dirname(readlink($argv0)); elif ... Sorry for the pseudo shell code, but the equivalent c code isn't much different.I'm rather unfamiliar with that, any snippet of code available?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.
Aug 05 2006
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Walter Bright schrieb am 2006-08-05:Frank Benoit wrote:| #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-----I'm rather unfamiliar with that, any snippet of code available?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.
Sep 20 2006
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. SeanWhen 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
Aug 08 2006
Bruno Medeiros wrote:Sean Kelly wrote: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.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. SeanWhen argv[0] isn't an absolute path, then isn't the location of the executing process file = CWD ~ argv[0] ?
Aug 08 2006
BCS wrote:Bruno Medeiros wrote:Agh, of course, that was silly of me. :Z -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#DSean Kelly wrote: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.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. SeanWhen argv[0] isn't an absolute path, then isn't the location of the executing process file = CWD ~ argv[0] ?
Aug 08 2006
http://d.puremagic.com/issues/show_bug.cgi?id=278 bugzilla digitalmars.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED Fixed DMD 0.164 --
Aug 11 2006
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 | 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. --
Sep 20 2006
http://d.puremagic.com/issues/show_bug.cgi?id=278 Created an attachment (id=38) --> (http://d.puremagic.com/issues/attachment.cgi?id=38&action=view) fixed inifile.c --
Oct 14 2006
http://d.puremagic.com/issues/show_bug.cgi?id=278 I ran into this today. Since a fix is attached, any chance this will be included in the next release? --
Oct 28 2006
http://d.puremagic.com/issues/show_bug.cgi?id=278 andrei metalanguage.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrei metalanguage.com Severity|normal |regression In dmd 2.005 on ubuntu, dmd.conf is not inspected whether it's in $HOME or the same place as the dmd executable. --
Oct 06 2007
http://d.puremagic.com/issues/show_bug.cgi?id=278 david acz.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david acz.org Version|0.163 |1.022 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 --
Oct 08 2007
http://d.puremagic.com/issues/show_bug.cgi?id=278 braddr puremagic.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED 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 --
Oct 13 2007
http://d.puremagic.com/issues/show_bug.cgi?id=278 Daniel919 web.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | -[ /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 --
Oct 13 2007
http://d.puremagic.com/issues/show_bug.cgi?id=278 If this is fixed, it should be closed. --
Jun 24 2008
http://d.puremagic.com/issues/show_bug.cgi?id=278 Brad Roberts <braddr puremagic.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |braddr puremagic.com Resolution| |FIXED PDT --- 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 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 07 2009