Date: Wed, 7 Aug 1996 19:59:36 -0700 (MST) From: Don Yuniskis <dgy@rtd.com> To: fqueries@jraynard.demon.co.uk (James Raynard) Cc: dgy@rtd.com, questions@freebsd.org Subject: Re: perhaps i am just stupid. Message-ID: <199608080259.TAA26772@seagull.rtd.com> In-Reply-To: <199608080028.AAA05336@jraynard.demon.co.uk> from "James Raynard" at Aug 8, 96 00:28:54 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608080259.TAA26772>