Message-ID:	<32582106.2174@cs.com>
Date:	Sun, 06 Oct 1996 14:13:42 -0700
From:	"John M. Aldrich" <fighteer AT cs DOT com>
Reply-To:	fighteer AT cs DOT com
Organization:	Three pounds of chaos and a pinch of salt
MIME-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC:	DJGPP Workers Mailing List <djgpp-workers AT delorie DOT com>
Subject:	Re: DJVERIFY 0.1a uploaded
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 961006184830 DOT 2485K-100000 AT is>

Eli Zaretskii wrote:
> 
> Comments:
> 
>         1) The messages that indicate problems (like when $DJGPP is not
> found) should attract attention in both the text printed to the screen and
> the report file.  Make them stand out (with asterisks, exclams, preceeded
> by ``ERROR:'' or with anything else), and print them surrounded by blank
> lines).  Right now they are lost among the voluminous output, most of
> which is just saying the gory details.  (I unset $DJGPP to see what
> happens and at first thought that the program didn't detect this, since no
> error message caught the eye.)

Agreed.  When I finish I intend to stand them out not only with
separation but with making them appear "high-intensity" on the screen. 
I _know_ that all monitors support that!

>         2) I would suggest to call the `bug report' a `system report' or
> some such, at least in cases where no problems were detected.

Thank you.  :)

>         3) When no problems were detected, I suggest telling this as the
> last line of the report, both to the screen and to the file.  And make
> this line stand out also.

Excellent idea!

>         4) The program should IMHO test explicitly for the frequent case
> of embedded blanks in $DJGPP, and yell bloody murder if it sees this.  I
> keep seeing before my eyes the wise guy who will just shrug, thinking
> that he did define $DJGPP and disregard the rest of report as ``useless
> crap''.

I hadn't gotten around to evaluating the environment in detail yet; I
just did enough to be able to invoke the correct DJGPP programs to test
memory and compilation.  That's in the works as we speak.

>         5) Why a separate batch file?  I think DJVERIFY itself should be
> a batch file, so users won't need to remember 2 names.

There is a real reason for this, and one to which I found no readily
apparent workaround:  the order of precedence in which COMMAND.COM
searches for files.

Do you remember the "port" of whence that I mentioned a while back?  I
discovered while making it that COMMAND.COM searches for executables
with a given stem in the following order:  .COM, .EXE, .BAT.  It doesn't
matter what order the files are in the directory - batch files always
get run _only if_ there are no other executables with that base name, or
if they are called explicitly.  So if I had DJVERIFY.EXE and
DJVERIFY.BAT in the same directory, typing 'djverify' would _always_
invoke the .EXE.

Faced with this dilemma, the only solution is to call the batch file
something else, and try to make it intuitive enough so that users will
be able to figure it out for themselves.  If anybody else knows a
workaround for this, please tell me.

>         6) I only glanced at the source for a few minutes, so I might be
> wrong, but it seemed to me that the programs are run by prepending the
> value of $DJDIR to them.  If so, I think this is not the best way.  Why
> not try to just run them?  If they are on the $PATH, they will run, even
> if $DJGPP is not set, and you get to diagnose more problems (and maybe
> even be smarter about them, knowing that the programs are installed after
> all).

The idea for now is to make sure that the programs can be run even if
the PATH is _not_ set correctly.  The main objective for that
djgpp_bin_location field is to ensure that the test compilation can be
run even if nothing else can, because it is needed for the "system
report".  I will add a more extensive PATH testing mechanism to the
initialization and diagnostic code to ensure that the correct programs
will be found no matter what the user's settings are.

> There is also a function called `searchpath' in the library which will
> help you look for a file along the $PATH without running it, which might
> be an alternative way of doing the above.

Yep!  Already working on it.  :)

Thanks for your help!

-- 
---------------------------------------------------------------------
| John M. Aldrich, aka Fighteer I  |        fighteer AT cs DOT com         |
| Plan:  To find ANYONE willing to |   http://www.cs.com/fighteer   |
| play Descent 2 on DWANGO!        | Tagline: <this space for rent> |
---------------------------------------------------------------------

- Raw text -