Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Aug 1996 09:07:59 -0700 (MST)
From:      Don Yuniskis <dgy@rtd.com>
To:        tcg@ime.net
Cc:        dgy@rtd.com, fqueries@jraynard.demon.co.uk, questions@freebsd.org
Subject:   Re: perhaps i am just stupid.
Message-ID:  <199608071607.JAA03687@seagull.rtd.com>
In-Reply-To: <3208BC55.124F@ime.net> from "Gary Chrysler" at Aug 7, 96 11:55:01 am

next in thread | previous in thread | raw e-mail | index | archive | help
It seems that Gary Chrysler said:
> 
> There *must* be some major confusion between us!

Yes, the major f*ckup was my assumption that the files were of the form
	bin.000, bin.001, bin.002, etc.
(I use a split(1) that creates files named thusly instead of bin.aa,
bin.ab, bin.ac, etc.)    <:-)

> > Argh!  I had assumed there was a cksum.exe   I'll look into booting
> > DOS and compiling it...
> 
> No there isn't .. Especially one that outputs the EXACT same output

Yes, I realized this, too (belatedly).  I was just getting ready
to compile cksum under DOS...

> that FreeBSD's cksum outputs.. They must AGREE 100% ie: The output
> must be exactly the same else comp will fail!
> 
> I probably already ported cksum. I'll have to go look! I borrowed
> the crc code for a PtoP network file transfer package I wrote. :)
> 
> Also Unix \n versus Dos's \r\n must be accounted for!
> comp will fail over this!

Yes, but if you use the same sources and *don't* use "text mode"
for file access, all should be well...

> > > 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.  Also cuts down
> > on the maintenance of yet another piece of software (and, is more
> > in tune with the UNIX philosophy of building with existing tools).
> 
> I'll buy that!
> But, Um, We are talking about the Dos side! The unix side is
> already doable! For both, The creation of checksum.sum for dos
> systems, And for testing such files on a Unix system.

Right.  But you can still do things "The UNIX Way" (Tm. Reg.)
even though you're running under DOS!  :>
 
> > >          cksum %1.?? > %1.tmp
> > >          comp %1.sum %1.tmp
> > >
> > > I belive this is what you meant. (That is if all the binarys have a
> > >  two digit extension)
> > 
> > But, it will hose you if foo.xx exists, etc.
> 
> I would hope that foo.xx exists since that is the file that is
> to be checked sum'd against the checksum.sum created by FreeBSD.org
> 
> cksum foo.xx > foo.tmp
> 
> In plain english:
>     send cksum of foo.xx to file foo.tmp (Overwrite if exist)

Yes, the problem was my assuming that the files to be checksummed
were of the form foo.0?? (or foo.0* as a DOS-ism)

> > 
> > >       cksum %1.* > %1.tmp
> > > Would cause the .tmp and .sum to be cksum'ed.
> > >
> > >       cksum %1.0* > %1.tmp
> > > Whats the      ^.. for??
> > 
> > So the .tmp and .sum would NOT be cksum'ed!  :>
> 
> And how is this to stop that??
> 	foo.0* means any foo.0xx
> Where xx means anything or nothing.

*If* the files to be checksummed were of the *.[digit][digit][digit]
form, (assuming the first digit was "0"), then %1.0* would NOT match
the *.tmp, *.sum, etc. but *would* match each of the file names.
Again, my screwup... Mea Culpa, Mea Culpa, Mea Culpa...  (or, as my
ex used to say:  "My Coacoa, My Coacoa, Oh My Coacoa!")
 
> > > > Briefly, this cksums all files in a given group (bin.*, sbin.*, etc.)
> 
> This will cksum only bin.0*, sbin.0* not bin.* or sbin.*.
> AFAIK those *.0* files don't exist, AFAIK they are named:
> 	bin.aa
> 	bin.ab
> 	...
> 
> > > > *except* for the ".sum" file and the ".tmp" file of the same name
> > > > (e.g., bin.sum and bin.tmp -- DOS creates bin.tmp to catch the output
> > > > of the cksum command.  But, if you said 'cksum %1.* > %1.tmp', DOS
> > > > would pass %1.tmp to cksum, too!  :-(   Now, you have %1.tmp holding
> 
> Who said anything about 'cksum %1.*' ??
> I didn't. I said 'cksum %1.??' There is a huge difference!
> Of course this will cause a problem if the files ever go beyond
> a 2 digit extension.. I don't see that happening.
> Still have numeric values if zz is reached.
> (I don't know what they are up to though)

Yes, Yes, Yes.  (Again, *.0* screwup)
 
> > > > the computed checksums for all of the %1.0* files.  Presumably,
> > > > %1.sum (e.g., bin.sum) would already contain the checksums for these
> > > > files -- because they were computed in the same way from the
> > > > *originals* at freebsd.org.  Then, 'comp' (roughly the equivalent
> > > > of cmp(1)) just does a compare between the two files.
> > >
> > > I don't understand where you get the .0* from..
> > 
> > See above  (Uh, d'uh....)  :>
> 
> Uh, d'uh What??
> 
> I still don't understand where you get the .0* from.
> 	%1.0* would result in foo.0xx
> where xx is anything or nothing!
> 
> Like I said at the very begining of this message!
> We must be on two totally different wavelengths. :)

Yes.  If you reread all of this with my original f*ckup in mind, it
should all make (wrong) sense!  <;-)

--don



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608071607.JAA03687>