Path: utzoo!bnr-vpa!bnr-fos!bigsur!bnr-rsc!mlord
From: mlord@bnr-rsc.UUCP (Mark Lord)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: Bug in APPENV
Keywords: appenv bug
Message-ID: <1303@bnr-rsc.UUCP>
Date: 21 Oct 89 03:33:46 GMT
References: <8111@microsoft.UUCP>
Reply-To: mlord@bnr-rsc.UUCP (Mark Lord)
Organization: Bell-Northern Research, Ottawa, Canada
Lines: 40

In article <8111@microsoft.UUCP> phillipg@microsoft.UUCP (Phillip Garding) writes:
>I have just decoded and tried out Mark Lord's program APPENV, and I
>have discovered a rather nasty bug.  The documentation doesn't include
>...
>In my environment I have these two variables:
>	TERM=vt52
>	TERMCAP=c:\editors\termcap
>
>As a test, I was going to append to my TERM variable.  I entered:
>	APPENV TERM = hello (with the spaces)
>
>I expected to see TERM=vt52hello; what was actually in my environment was
>	TERM=vt52
>	TERM=P=c:\editors\termcaphello
>
>This bug appears if you define a new variable that begins with the same 
>letters as a previously existing variable.  The problem seems to be with the
>spaces, since it doesn't do it if I type APPENV TERM=hello.  In that case
>I get the expected result.

Good one!  Yes, everything does indeed work just fine without spaces before
the equal sign.  I have now fixed this and will be sending APPENV version 2.1
to SIMTEL20 to replace (buggy) version 2.0 there.  Probably not worth a repost
to comp.binaries.ibm.pc though.  

To fix this bug in the source, simply change line 92 of appenv.c as follows:

	OLD line 92:	while ((*e++ == *v++) && (*v));
	NEW line 92:	while (*e == *v) ++v, ++e;

Then recompile appenv.c under the TINY model of turbo-c, and use TLINK with
the /t option to create a new APPENV.COM.  If anyone is really desparate,
email me (by replying to this message from within rn) and I'll consider 
forwarding you the updated version.

Cheers,

-Mark

utgpu!bnr-vpa!bnr-fos!mlord%bmers58