TIP: Click on subject to list as thread! ANSI
echo: batpower
to: Paul Quinn
from: Richard Webb
date: 2009-06-11 13:02:52
subject: reconciling data two different sources, yo batch gurus!

Hi Paul,

On Thu 2037-Jun-11 15:29, Paul Quinn (3:640/384) wrote to Richard Webb:


 RW> Any ideas welcome on how to streamline this.  OF course,
 RW> we're backing up our input data before we do this until
 RW> we're sure we've found all the bugs.

PQ> It ain't broken, is it Richard?  I've pinched a copy for my archive.
PQ> One day, when I take the time to understand how fgrep386 and sed
PQ> actually do their stuff, I might understand it more fully.

Nope, surprisingly enough, it worked first time out of the
gate!!!

the thing with fgrep386, which I renamed to fgrep I use it
so much, is that it's a literal search, where ms dos find
will be a little fuzzy on the search logic.  search on
"foobar" with fgrep386 and only "foobar" standing alone
will be a match.  FInd otoh will match foobar-program or
foobar_data, etc.  IF I want a bit of fuzzy I use find.  For a literal it's fgrep386.

PQ> My only comments are these: you might consider replacing the use of
PQ> "rem" statements with double colons, because Command.Com is still
PQ> looking at those lines and trying to make some sense out of them;
PQ> and, you could think about dropping the double errorlevel tests "if
PQ> errorlevel 0 if not errorlevel 1 goto postit" completely, since at
PQ> that point anything there will be in a fall-through condition - just
PQ> leave "goto postit" there instead.  (Remember that with "if
PQ> errorlevel X" checking, Command.Com is comparing the
"X" value -and-
PQ> greater.  Since you've already checked for X+1 previously then
PQ> another check is superfluous.)

True, old habits with the errorlevel checking.  That was a
quick and dirty job .

PQ> Besides that, the only other thing that might shave off another
PQ> nanosecond would be to do the 'number of lines in the file' test on
PQ> a single line, essentially looking for a value that cannot be in the
PQ> file.  That is, instead of: 

PQ> [ ... ]
PQ> echo * >> lognum.sem
PQ> type lognum.sem | find "*" /i /c >> lognum.txt
PQ> nset lognum=$1  [ ...]

YEp, but finding the line number is part of what happens if
we "goto postit" because it's grabbing that line using sed
to our output file.  Also, lognum.sem is used at the end of
the process as a counter.  A habit I got into years ago when I wanted to
count something such as the number of executions or something similar. 
Bang a certain character into a file.

I have one elsewhere that if it does something it appends a
* character and the usual cr/lf to said file, if it doesn't
it appends "#" and cr/lf.
I"ll play with your suggestion.  I'm fairly happy with it
though.  Glad you liked it!  EVen more glad it ran first
time after I created it without doing anything stupid like
dumping all over my data.

PQ> Good job with it so far.  It's a keeper for me.  :)

AS I commented, glad you liked it.  I've been cogitating on
ways to reconcile the two for awhile, and when we had a
glitch in one source of the information and then it was
intermittent I started utilizing second source and was doing reconciliation
by hand and said the old "this is stupid" and quickly wrote that
little batch program.

Regards,
           Richard
--- timEd 1.10.y2k+
* Origin: Radio REscue net operations BBS (1:116/901)
SEEN-BY: 10/1 3 11/331 34/999 120/228 123/500 128/2 187 140/1 222/2 226/0
SEEN-BY: 249/303 250/306 261/20 38 100 1381 1404 1406 1410 1418 266/1413
SEEN-BY: 280/1027 320/119 393/68 396/45 633/104 260 267 285 640/954 690/682
SEEN-BY: 690/734 712/0 313 848 800/432 801/161 189 2222/700 2320/100 105 200
SEEN-BY: 5030/1256
@PATH: 116/901 3634/12 123/500 261/38 633/260 712/848 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.