Question: What's your longest batch file?
Jim Robinson
one 600+ line script (most of which is error checking and logging).
That got me to wondering what the longest production script the folks
here who really know what they're doing have written.
I'm just curious.
--
Jim Robinson
set email=jim....@ix.netcom.com
echo %email:.n.=n%
guard
> I just finished (for now) combining a bunch of little 'functions' into
> one 600+ line script (most of which is error checking and logging).
>
> That got me to wondering what the longest production script the folks
> here who really know what they're doing have written.
>
> I'm just curious.
Our longest here is NTLibSrc.cmd at 4700+ lines and growing daily. We use
this fully commented command source script to create our production builds
of the Expert Command Library (NTCmdLib.cmd). The source script is fully
executable but slightly slower than the final version.
Our Code Compression Engine (!Compress.cmd, now in beta 3) removes all
non-essential scripting code, creating a functionally identical runtime
containing under 700 lines.
Here is the output from a recent build:
----------------------------------------------------------------------------
-
!Compress - Expert Version {beta 3}
----------------------------------------------------------------------------
-
Source File: NTLibSrc.cmd
Destination File: NTCmdLib.cmd
Total Lines In Source: 4716
Blank Lines: 978
Comment Lines: 1364
Help Lines: 35
Lines In Destination: 2374 {before multiline compression}
: 686 {after multiline compression}
Total Lines Removed: 4030
Source File Size: 215796
Destination File Size: 89042
Compression (Lines): 85%
Compression (Bytes): 58%
Embedded (Lines): 7802
Embedded (Bytes): 310652 {estimated}
Final Size On Disk: 399694 {estimated}
Extra Compression: 0 lines, 0 bytes
____________________________________________________________________________
_
[Thu 04/14/2004 02:37:46] !Compress.cmd Release 2004.xx.xx - Task Complete.
*******
We extensively use both the source and "compressed" versions in production
and in our testing facilities. The client base uses the production
NTCmdLib.cmd in a wide variety of configurations from single user machines
to multi-entity enterprise networks.
Our FREE Advanced Library (ntlib.cmd) weighs in at 2782 lines of executable
source script, compressed to 467 lines of runtime.
Additional information at:
(http://NTCmdLib.com)
(http://TheSystemGuard.com/NTCmdLib.asp#LibraryArchitecture)
(http://ntlib.com)
(http://TheSystemGuard.com/default.asp#MasterCommandList)
*******
-tsg
/-----------------+---------------+----------------------\
| COMPATIBILITY | CLARITY | SPEED |
| Write code ONCE | Make it clear | THEN...Make it fast! |
\-----------------+---------------+----------------------/
400+ command-line resources using ONLY native NT commands!
(http://TheSystemGuard.com/default.asp#MasterCommandList)
Ted Davis
<jim....@ix.netcom.com> wrote:
>I just finished (for now) combining a bunch of little 'functions' into
>one 600+ line script (most of which is error checking and logging).
>
>That got me to wondering what the longest production script the folks
>here who really know what they're doing have written.
>
>I'm just curious.
I created one several years ago that was over 55000 commands. There
have been some since that were probably longer, but I didn't check
their size. These days it isn't necessary to build such large
programs nearly as often because FOR allows such precise manipulation
of directory trees and other things.
T.E.D. (tda...@gearbox.maem.umr.edu)
SPAM filter: Messages to this address *must* contain "T.E.D."
somewhere in the body or they will be automatically rejected.
Jim Robinson
news:h42t705fq3qj7i2pu...@4ax.com:
<snip>
> I created one several years ago that was over 55000 commands.
</snip>
That sounds like COBOL, not batch. It must have been a bear to test.
Ted Davis
<jim....@ix.netcom.com> wrote:
>Ted Davis <tda...@gearbox.maem.umr.edu> wrote in
>news:h42t705fq3qj7i2pu...@4ax.com:
>
><snip>
>> I created one several years ago that was over 55000 commands.
></snip>
>
>That sounds like COBOL, not batch. It must have been a bear to test.
It was very repetitive -same command 55000 times with different file
names. It took almost a day to run and I figured that individual
commands would be much faster than any way of running a subroutine for
each file under DOS 5.
Al Dunbar
"Jim Robinson" <jim....@ix.netcom.com> wrote in message
news:RPpfc.11278$A_4....@newsread1.news.pas.earthlink.net...
> I just finished (for now) combining a bunch of little 'functions' into
> one 600+ line script (most of which is error checking and logging).
>
> That got me to wondering what the longest production script the folks
> here who really know what they're doing have written.
Regardless of Ted's 55000 line example, most of those who *really* know what
they're doing manage to keep their scripts down to a reasonable length ;-)
/Al
noel...@gmail.com
Auric__
> On Wednesday, April 14, 2004 at 11:19:29 PM UTC-7, Jim Robinson wrote:
>> I just finished (for now) combining a bunch of little 'functions' into
>> one 600+ line script (most of which is error checking and logging).
>>
>> That got me to wondering what the longest production script the folks
>> here who really know what they're doing have written.
>>
>> I'm just curious.
>
> is around 2,300
--
This book reads like stereo instructions.
Tim Rude
until now to finish it. :)
jadi...@gmail.com
scripts I have in the BLIP batch library on sourceforge. It basically does
the equivalent of a configure, make, and building an installer for an app
that's part Java, part C, with a few little interactive components for
configuring the type of build (e.g. debug/release), running the build after
compilation and versioning the installer.
I also had a pretty large batch script to collect ping information of computers
on the network before pushing out updates since people would turn off their
computers for the day. I also had several scripts that would do database
maintenance that like adding/deleting users, cleaning log entries, etc, when
I was managing an application database.
Don't use batch scripting every day, but in the right scenario it can save
hundreds of man hours in the long run.
Best regards,
John D.
garyde...@gmail.com
and growing