I believe Batch files were available when the first IBM PC hit the market around 1980. They have evolved a little. Batch commands have changed to handle more options, a little more versatility has been added here and there. How come, after 28 years they are still around, and they don’t seem to be going away any time soon? Well, if the task to be performed is not large enough to write code in a compiled language, and not simple enough to do it manually, the batch file is the right answer! It’s fast to write, easy to understand (well, not always), and easy to change. They do have an expensive aspect, though. They are hard to tune up and get running right. A simple mistake can be very hard to find and correct: misspelling a label can result in the wrong execution path; a space in an assignment will result in the wrong assignment, a space in a file name can change execution fatally if the code is not solid. Yes, but with all their frailties and difficulties, we continue to use them.
So who uses batch files? Home users? maybe here and there for some repetitive tasks. But the main users are large companies. They are used in backup processes, in file purging processes, program installations (before setup.exe is ready for prime time), changing user permissions, preparing machines for special code runs, copying data, etc.
Well, batch files can do many things, and be very powerful. Some batch files have thousands of lines of code. They can handle easily jobs which are more cumbersome in other languages, like starting and stopping services.
I will write about different aspects of batch files. Today, writing batch files is easier with the introduction of a very cool product: Running Steps. It’s a full featured debugger and code analyzer for batch files. It can cut your development time significantly. It will tell you about your mistakes before you need to dig into your code to find them because something is not executing right. The code analyzer will check your code as you type. It’s a syntax check, even though it goes beyond syntax. Let’s say, I have been programming in C# or C++ all day, and move on to change a batch file. I type the following line:
set MyVariable = new value
Looks fine at first sight, right? Weill, it’s not. Running Steps will display a wiggly line after the variable name. Both the variable name and the value have a space which may not be intended to be there. The variable name is ‘MyVariable ‘ (with a space at the end). Catching this type of issues during execution is a pain. The simpler the mistake, the harder it is to catch.
That is why having a tool to debug batch files is awesome. It will help identify problems before they execute. Running Steps will also allow me to step through my code, set breakpoints, watch/edit variable names, etc. Just what you would expect from a good debugger.
So, I invite you to check it out. You can find it at http://www.steppingsoftware.com . I will be writing more about batch files, common faults, cool programming practices (check some cool information in the ‘Batch File Coding’ forum Stepping Software has created), use of variables, common pitfalls, etc.
I guess this is a good starting point for a blog on Batch Files. Eventually cool tricks and techniques will be all found here.
Enjoy!
GISkier
Tags: Batch, Batch Files, Debugger
