www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 278] New: dmd.conf search path dosn't work

reply d-bugmail puremagic.com writes:
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
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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
next sibling parent reply BCS <BCS pathlink.com> writes:
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?
Aug 03 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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!)
Aug 04 2006
parent reply Sean Kelly <sean f4.ca> writes:
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
Aug 04 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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
parent reply Sean Kelly <sean f4.ca> writes:
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
Aug 04 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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
parent reply Frank Benoit <keinfarbton nospam.xyz> writes:
 
 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
parent reply Walter Bright <newshound digitalmars.com> writes:
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?
Aug 05 2006
parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----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-----
Sep 20 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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
Aug 08 2006
parent reply BCS <BCS pathlink.com> writes:
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.
Aug 08 2006
parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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
Aug 08 2006
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
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.
Aug 05 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
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


-- 
Aug 11 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
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.


-- 
Sep 20 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
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


-- 
Oct 14 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
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?


-- 
Oct 28 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
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.


-- 
Oct 06 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
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




------- Comment #10 from david acz.org  2007-10-08 09:58 -------
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=278


braddr puremagic.com changed:

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




------- Comment #11 from braddr puremagic.com  2007-10-13 13:49 -------
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=278


Daniel919 web.de changed:

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




------- Comment #12 from Daniel919 web.de  2007-10-13 15:11 -------
-[ /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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=278





------- Comment #13 from bugzilla digitalmars.com  2008-06-24 22:25 -------
If this is fixed, it should be closed.


-- 
Jun 24 2008
prev sibling parent d-bugmail puremagic.com writes:
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




--- Comment #14 from Brad Roberts <braddr puremagic.com>  2009-06-07 12:55:14
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