Today, I’m discussing a primitive technology that is so useful to my team of technical communicators that I cannot overstate its importance: the batch file. This blog might be a bit of a yawn for those people who know batch files well, and remember enhancing the autoexec.bat file that ran whenever they started their personal computer in the ’80s and ’90s – so if you’re one of those people, your role in this whole venture might be to chip in with use cases and coding advice!
So: what’s a batch file, I hear (some of you) cry?
From http://searchwindowsserver.techtarget.com/definition/batch-file: A batch file is a text file that contains a sequence of commands for a computer operating system.
Hmm – that sounds dry. Let’s put this definition into a real world context. As a technical communicator, you use your authoring tool of choice to write brilliant instructions, or policies, or processes, or some killer combination of all the above. To go live, you may have a sequence of steps you need to perform. I don’t know what yours are, so I’ll talk about mine – but bear in mind that batch files are what you make them.
At my workplace, we’ve been using batch files now to streamline the final steps in publishing live and draft content for more than a decade. If I didn’t use batch files, I’d have checklists that would list a whole lot of manual and tedious steps. We publish all our live and draft content to websites, and if I were to explain the steps that are required to do this, they might look like this:
- Publish [the content] to HTML
- Copy some other required files (e.g., spreadsheets and documents) to the publishing folder
- Run the Zoom indexing program across the folder to catalogue the contents
- (For live content) Make a zipped backup copy of the live webfolder before we change the contents, and put it in the archive
- Delete the old content and copy across the new content
- Send us an email to advise that this process is finished
If we used a checklist to ensure all of these steps happen every time we update the online manual, it would take a lot more time, be more error-prone, and would require the writers to develop some quite technical expertise that they don’t really need. So instead, we write a batch file which tells the operating system all the steps we want it to run on our behalf. When the writer is ready to trigger the commands, they start the batch file and then get on with other work while it completes. A simplified version of the batch file described above might look like this:
Our workplace is operating in a Windows environment, but underneath Windows is the very same MS-DOS (MicroSoft Disk Operating System) that has been running PCs since before Windows was a sparkle in Bill Gates’ eye. If you know how to operate the MS-DOS command line, batch files are a doddle. If you don’t, you’ll probably need a bit of training to get started. There are lots of resources available on the web – such as http://www.wikihow.com/Write-a-Batch-File.
Do you use batch files in a non-Windows environment? Tell us about it!
Should TCANZ provide a webinar on this subject? If you think we should, please let us know.