From owner-freebsd-questions Wed Aug 7 20:00:01 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA29098 for questions-outgoing; Wed, 7 Aug 1996 20:00:01 -0700 (PDT) Received: from seagull.rtd.com (root@seagull.rtd.com [198.102.68.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA29054 for ; Wed, 7 Aug 1996 19:59:46 -0700 (PDT) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id TAA26772; Wed, 7 Aug 1996 19:59:36 -0700 (MST) From: Don Yuniskis Message-Id: <199608080259.TAA26772@seagull.rtd.com> Subject: Re: perhaps i am just stupid. To: fqueries@jraynard.demon.co.uk (James Raynard) Date: Wed, 7 Aug 1996 19:59:36 -0700 (MST) Cc: dgy@rtd.com, questions@freebsd.org In-Reply-To: <199608080028.AAA05336@jraynard.demon.co.uk> from "James Raynard" at Aug 8, 96 00:28:54 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > So, Why waste time doing both.. a Dos based cksum compatiable with > > > FreeBSD's cksum's output as well as a kludge'y batch file! > > > It would be just as easy to whip up a dos based program that > > > read the *.sum files and compared them to the files on the fly! > > > > I would advocate *against* modifying the code for this. Put that > > functionality into a .BAT file wrapper. This allows someone > > already knowledgable in cksum(1) to modify the BAT file without > > having to learn some bogus *new* MyCksum program. > > I don't like the batch file idea at all. And assuming that users > will FTP down the files in alphabetical order (which I think you > mentioned in another post) is just asking for trouble. Granted, assuming alphabetical order is a LOSE LOSE. > > Also cuts down > > on the maintenance of yet another piece of software > > But we've already introduced more maintenance work - someone has > to generate these checksums every time a new release comes out. This is a "one liner" in a makefile... no code to write or maintain to *generate* the checksums... > This program shouldn't need much maintenance - all it will need for > each release is a config file that tells it what distributions are > available and which files are in each one (in fact, I believe that's > what the *.inf files in 2.1.5 do). > > > (and, is more > > in tune with the UNIX philosophy of building with existing tools). > > If we were talking about a Unix environment you would have my 101% > agreement. Unfortunately, DOS was designed on the philosophy that > a program has to do everything itself; the "shell" is practically > useless for anything more than launching applications. As for the > OS, well, why do so many DOS programmers talk directly to the > hardware? You don't *really* want me to answer that, do you??? ;-) > > It hardly seems worth any "performance increase" to replace DOS's > > batch file interpretter with hardcoded system("cksum.exe") > > You don't have to call system() - just hack cksum's command-line > handling so it reads the names from a file instead and sorts them into > alphabetic order. Put #ifdef MSDOS/#endif around this if it makes you > happier :-) > > (BTW what's the max length of a DOS command line? The bin.* files > in 2.1.0 are 6 chars long, and there's 82 of them, plus a space > between each one - that's getting on for 600 chars by my reckoning). I would do the globbing in a batch file. > Once you've done that, then adding a couple of lines to read in > a number from a file and compare it to the number you first thought > of is trivial. > > I do understand why you want to do this in as Unix-like a way as > possible, but I don't think it's workable. Sorry. Yes, I suspect that's the case. I would almost advocate porting grep and sort just so a UN*X-like approach *could* be employed -- seems like it would be easier to maintain. Porting cksum was a no-brainer. Though I imagine grep *might* be a bit more involved for some of the funkier switches, etc. I think even just having CKSUM.EXE available would be *some* consolation to those folks that are banging their heads against the wall wondering why the gunzip is failing, etc. I'll try to get back to digging through the code when I finish rebuilding my alternator... :-( --don