|
|
|
But if you're going to go to all that trouble...
|
| The Trouble... Almost every programming/scripting language has libraries of accepted solutions available so everyone doesn't have to reinvent the wheel. Whether they are called DLLs or "code snippets" or "routines", commonly needed solutions are developed and refined over time so coders can concentrate on the core problem that their script or application is supposed to solve. Multiple solutions are normally placed in a single library and then called by other programs using a standard syntax Then the world makes progress. One glaring exception was the builtin shell scripting that is present on every installation of every Windows OS that uses the NT Code Base (includes everything since NT4SP6a+). While you can find a variety of "tips and tricks" web sites or how-to books on this subject, you still have to memorize a multitude of special cases and exceptions, as well as navigate numerous "Syntax Ditches", in order to write a Reliable Cross-Platform Shell Script. In other words, a script that will perform CONSISTENTLY across operating systems and configurations using code that can actually be understood and maintained over time. Add to this the fact that, also unlike most other languages, many of the persons writing these "little batch files" have And finally, it is increasingly common to see restrictions on installing any "third party software", even though these same "restricted systems" usually allow batch/shell scripts to be run by the local SysAdmin regardless of that person's skill level. The reality is that many are made "responsible" for System Administration, but not given adequate time or training to do the job (because their REAL JOB is "office manager" or "plant controller").Before TheSystemGuard.com released it's Command Libraries publicly in late 2002, only our consulting clients enjoyed their benefits. The world of NT-based shell scripts was, comparatively, in the age when you had to have a different LaserJet Print Driver for each DOS application (remember the old WordPerfect "Printers Disk"? - can't use that driver to print from Lotus 1-2-3).T here was no standardized method to stop "rehashing the same convoluted code" every time you needed to write a batch file. You either built up your own "library" of code or you searched the Web/Newsgroups and tried to figure which one of the 1000s of hits was best for your situation.The Answer! Since releasing the Advanced (ntlib.cmd) and Expert (NTCmdLib.cmd) Libraries, the Even if third party software is allowed, the se Command Libraries replace dozens of small utilities in your toolbox and gives you, whether you are a programmer or not, the ability to "create" your own new commands and utilities using our "Pattern Scripts". Another advantage, in a larger organization, is the ability to deploy complex scripts from a central location to local, less experienced SysAdmins without having to provide daily explanations and assistance.The success of our products is based on feeding someone a good hot meal WHILE we teach them to plant, harvest and prepare their own food (it's hard to learn when you're starving).To do this, w e use a "ThreeFold Cord of Knowledge":COMPATIBILITY CLARITY Make the code UNDERSTANDABLE--to ALL.SPEED Optimize that Understandable code.Our Command Libraries and MountCommands strike a balance between the need for solutions that can be understood by the less experienced SysAdmin, and the need to write complex cross-platform scripts, often without using any "third party software". The actual complexity of writing shell scripts is still there, it's just that you can now use the script immediately and learn as you go, rather than having no choice but to blindly accept some cryptic code segment without understanding how it works.I t's easier to understand and remember a one-word "sounds like what it does" command than all the OS-specific variations of how to perform that action. The resources in the library dynamically adjust to differences in OS's and configurations so you write your script using a CONSISTENT syntax and you get CONSISTENT results.Now, the Entire Body of Knowledge relating to NT-based shell scripts is now MOVING FORWARD as each new standardized solution is added to the Expert NT/2K/XP/K3 Command Library by way of COMPATIBILITY, CLARITY and SPEED!The Details Single File Solution (NTCmdLib.cmd) Placing all resources within one file allows faster CALLs and resolves the problem of "my script needs xxx utility but it is not installed on all my systems". The library requires no install and does not have to loaded locally. It will perform CONSISTENTLY when called using UNC naming and does not even require a mapped drive letter. Normal operations can be performed with only Read access. This allows execution from Read-Only media like CD/DVD or Read-Only network shares. Standardized Self-Documenting Syntax Using the Command Library "feels like" using the native operating system commands and utilities with the added advantages of Cross-Platform (NT/2K/XP/K3) compatibility, self-documentation, and speed. For example, executing a library function uses the syntax "%.Call% $FUNCTION" just like calling a script uses "CALL Scriptname.cmd". With three types of executable code, any type of repetitive task can be added to the library. This includes "one-liners", which can be placed directly into RAM as .Mount/\Commands, single task $FUNCTIONS which perform one job, and complete scripts of any length implemented as :Procedures. Procedures can even use their own command line switches (just like standalone utilities) as well as the GlobalSwitches supported by the library itself. Code Compression Removes most white space and all indenting as well as squeezing the maximum number of commands and parameters into a single line of script code, reducing the overhead caused by reading an interpreted script one line at a time. The command interpreter (Cmd.exe) gulps down the script using the largest bites that it can handle. This is similar to using Jumbo Frames in Ethernet or zipping up a bunch of files before sending them to a remote system. One transaction (read a line of code) performs multiple tasks (execute multiple commands). "Almost Compiled" Code Using "Extreme MountCommands", a set of highly abbreviated internal library commands, the actual byte count on disk is further reduced. Code is expanded in RAM when loaded, reducing library initialization time and producing operational performance that is similar to a compressed executable file (.exe). Command Caching (.MountCommands) Preloading commonly used, session-specific, customized code segments into the local environment, where they can be executed directly from memory using a self-documenting syntax. These commands (like .GetDirSize, .ifServer, .Wait, etc.) perform just like internal commands such as FOR, ECHO, etc. Data Caching (#Constants) Preloads commonly used data values into the local environment, where they can be accessed directly from memory using a self-documenting syntax. These values (like #LogDate, #LogTime, #ServicePack) are always available after Library Initialization and can be accessed just like the native environment variables such as %USERNAME%, %Path%, etc. ADS-based Help System (!GuardNotes) NTFS Alternate Data Streams store a complete library catalog, retaining all the benefits of internal documentation, without affecting the performance of the library itself, which is stored in the main stream ($DATA). Copying the library file also copies the catalog (as long as you stay on NTFS-formatted media). The help system is expandable and can be edited or customized without affecting the operation or performance of the Command Library. ExactNames All internal utilities, and the library itself, are called using the syntax "CALL %.Find%" where .Find expands to the complete drive, path, filename and extension. This provides reliability (you always know exactly what you are calling) and a slight speed increase (system doesn't need to search the PATH and PATHEXT variables to see if you are wanting to execute find.com or find.exe, etc.). By specifying EXACTLY where to find the executable file, you have the option of relocating all external utilities to a secure area that is NOT in the system path. Command Line Switches Using the :Parse_Command_Line_Switches Procedure, scripts that are written using the library can accept (and actually use) command line switches just like the many small utilities that most admins collect. Self-documenting, session-specific, .Mount/\Commands remove any switches from the current command line, and allow you to branch based on the current switch state within your code. CmdShorthand ("Command Shorthand") Once you get familiar with the library, you can use the CmdShorthand at any Command Prompt. After initialization, the Command Library allows development and testing at the local command prompt with an absolute minimum of typing. What's In It For You We are confident that, if you write or maintain any shell scripts at all, you will find our Command Library to be priceless. It will be because you have found a low cost, high value product that you can use immediately, and that almost everyone needs. Whether you're a complete novice or a professional coder, YOU NEED THIS PRODUCT! Even if you're an expert that can make a % sign stand on it's head, you can write the same advanced code using our Command Library and someone with only basic "batch file" knowledge could understand and, if needed, edit the script without having to call you every time. And last of all The cost is |
| All of the commands and resources listed below are available without adding any additional software to a standard "out of the box" install of Windows NT, 2000, XP or Server 2003. If you use only these resources, your scripts will run CONSISTENTLY on all of these platforms (see the Compatibility Page for more info). |
Click a command to go to it's Mounted Help Page, or see the Master Catalog for brief descriptions. To see this list on it's own page, click here.
|