Path: utzoo!attcan!uunet!wuarchive!usc!apple!amdahl!kim From: kim@uts.amdahl.com (Kim DeVaughn) Newsgroups: comp.sys.amiga.tech Subject: Re: ls 4.0k Case Sensitive (was Re: CygnusEd Pro) Message-ID: Date: 28 Sep 90 00:54:07 GMT References: <1990Sep6.034821.9389@ecn.purdue.edu> <82=R02Cb02ds01@JUTS.ccc.amdahl.com> <1990Sep21.161025.14703@agora.uucp> Reply-To: kim@amdahl.uts.amdahl.com (Kim DeVaughn) Organization: Amdahl Corporation, Sunnyvale, CA 94086 Lines: 54 In article <1990Sep21.161025.14703@agora.uucp> billsey@agora.uucp (Bill Seymour) writes: > In article <82=R02Cb02ds01@JUTS.ccc.amdahl.com> ked01@ccc.amdahl.com (Kim DeVaughn) writes: > : > :Now, the (RSN) v4.1k version of ls will continue to provide internal wildcard > > And this one will fix that annoying problem with both 3.1 and 4.1 that > puts my 3000 into 'real, real slow speed' mode? It doesn't happen each time, [ Just to avoid confusion, the problem exists in v3.1 and v4.0k ... v4.1k has yet to be released. ] Yes, the problem has been found! There are several other, quite different ways it can manifest itself also, BTW. Henrik Clausen found that *his* manifestation of the problem disappeared if the standard Lattice "cres.o" startup code was used in place of the custom "mycres.o" code (thanks again, Henrik!). This also explains why v3.1 has the problem, as that code is identical in both 3.1 an 4.0k. Not having a 3000/2.0 myself, I haven't bothered to try and isolate exactly *what* in "mycres.o" was causing the problem though. The price paid for this solution is an increase of a few hundred bytes, which I think is "reasonable". Another plus, is that is by using the standard startup code, it allows me to use the Lattice getenv() function, rather than having to "roll my own" (though *that* fn() adds nearly a full 1K to the executable). Also, it means one less piece of code that needs to be supported. There was one further complication with this. Someone was getting "instant Guru's" using a test version of ls that was built using the Lattice v5.05 "cres.o", but when it was recompiled using the SAS v5.10 version, the problem went away. Since this was done under a beta version of a commercial product, I'm not sure where the problem really was, but that's why I've been waiting for my copy of SAS v5.10 to show up before releasing v4.1k of "ls". Which showed up yesterday ...!!! So, in summary, "ls" v4.1k will be along in not too long ... after some final beta testing, and it will be a bit larger than I'd like (feature enhancements aside). I will try and reduce the "bloat" in a subsequent revision, but I want to get something that works well with both 1.3 and 2.0 out ASAP. /kim -- UUCP: kim@uts.amdahl.com -OR- ked01@juts.ccc.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25