For Automated Testing, Better Alternatives To DOS Batch Files? 426
An anonymous reader writes "I am working on a project that would allow our customers to test out sending different PCL commands to LAN printers. My initial thought was that a DOS batch file will allow users to select some simple options, send the tests to printers, and even generate a small web page which, when launched from the batch file, will provide email feedback on the tool. This all worked. To spice it up I added some ANSI color commands to the menus, though the implementation of that may prove tricky without resorting to .COM files or forcing the load of the ansi.sys via the command.com shortcut. And this implementation goes against my initial idea that I want the entire thing to be contained in a standalone batch file. My questions are: Is there a better option for this? Are DOS Batch files too 1990s to be taken seriously in 2010? The application needs to (1) be simple (2) be easy to update (3) be able to send PCL commands to LAN-attached printers and (4) allow email feedback. I don't know what other programming language would allow this and be as simple. I tend to think that I have found the best tool for the job but if you have another idea let me know. Call me crazy but I love DOS."
You are... (Score:1, Insightful)
Crazy.
Re:DOS Is dead use visual basic (Score:3, Insightful)
Yeah. VB, C++, Java, they all do PCL commands.
Easiest way is to Build yourself a Win32 GUI, since thats what your users probably use already.
If It Works, It Works But Remember Your Customers (Score:5, Insightful)
Python would be my first choice. (Score:4, Insightful)
Re:perl? (Score:5, Insightful)
So far, I've gotten Strawberry perl to print to all of the printers on my network, run some old fortran programs successfully, update an in-house wiki automatically, automate e-mails to my co workers, and crash our entire network (that last one wasn't so much a feature, but hey, it shows just how powerful perl is). That said, I think with a bit of time and research you could probably get Strawberry perl to do exactly what you needed pretty easily. But I will warn you, when it comes to perl, I find that user experiences vary greatly.
Re:If It Works, It Works But Remember Your Custome (Score:4, Insightful)
Give them the documentation you have and do not say a word
If your product requires a manual than your user interface sucks.
Add a wizard for common scenarios... anything but documentation that no one will read.
I have a saying (Score:5, Insightful)
"If it's stupid and it works, it's not stupid."
There are plenty of doges you can use, perl, python, bash, and lots more. But all of them add a level of complexity to this that the batch file doesn't have. Which leads me to my second saying:
"If it's simple and it works, it's elegant."
Sounds like you've found an elegant solution to a problem. I'd stick with it if it works for you.
Re:perl? (Score:4, Insightful)
Probably the simplest solution would be to make a Win32 executable based on the Qt toolkit and statically linked. You get a single executable, a professional looking UI that took minutes or hours to build, and the advantage of a much more powerful and flexible language versus DOS batch files or even powershell scripts.
Qt also provides a dead simple class framework for accessing the network, so that will save you time. You can get Qt, including a really slick IDE for free from Nokia.
If .bat will do it, stick with .bat! (Score:5, Insightful)
PowerShell is the new Batch File Scripting, so if you need more power, learn PowerShell and use that. (I am assuming you're in a Windows environment where change of OS isn't an option.)
But DOS batch files still work just fine. In my last job at $major-hardware-vendor, we used DOS batch file-based menus all the time; because they were simple, they got the job done, and all the people who had any need to maintain them knew all about them. Some were particularly large/gnarly batch files, too. (Think 3 KB of one single .bat file menuing to do a few dozen tasks.) When choice is used liberally, along with variables, you can make it very simple to maintain, too. (We used it for updating various things, and the very first section was where all the variables were set, all you had to do when it came time to update was throw the updated file in the right place, and change a number in the batch file.)
Assuming nobody is whining... (Score:5, Insightful)
Your description suggests that, for anybody who doesn't really want to get their hands dirty, there is an adequate if rather retro menu driven interface. Great. A little reading never hurt anybody important.
Even better, if your application is written within the limitations of CMD batch files, it'll be trivial for any admin who cares and has a copy of notepad to pick it apart, if needed.
I, for one, fucking hate shiny-but-opaque vendor tools("Oh, great, you made it so easy that a trained monkey could do it, once. I need to do it 10,000 times, I see that your only officially supported method is '10,000 trained monkeys'. Would it have killed you to include some useful command-line options?". If your application is "send PCL test commands to networked printers" you ain't selling to grandma and cousin jim-bob. You may well be dealing with somebody who might need to programmatically test dozens or hundreds of printers. He will appreciate being able to rework your tool.
CMD sucks; but it ships with every version of Windows since ever, and(since you've already written your application) apparently its limitations didn't cripple you. Why mess with it?
Re:DOS Is dead use visual basic (Score:5, Insightful)
It is important to know your alternatives (e.g. you have many scripting options through cygwin, python, perl), but:
Use whatever works for you, and don't be ashamed just because it is not the current trend. You know your requirements (easy to maintain). Don't believe the people that say you have to rewrite everything.
Re:Python would be my first choice. (Score:4, Insightful)
nobody cares what you think.
I dunno. At least one guy cared enough to respond.
Re:DOS Is dead use visual basic (Score:5, Insightful)
They're also all a thousand times more complex than DOS.
Even simple VB Script is significantly more complicated than DOS batch files.
My advice? If it's internal to the company and only a few users are going to use it, a batch file is fine. If you're selling it, or a lot of people are going to be using it frequently, take the time to write a simple VB app to do the job. Something like this is so easy it would only take you an afternoon to do even if you've never used VB before, and it will look a much more professional.
If you want to just make a more professional looking wrapper for it, you can use shell commands in a VB app and not waste any of your work in the DOS script.
Re:DOS Is dead use visual basic (Score:3, Insightful)
4.3
A master was explaining the nature of Tao of to one of his novices. “The Tao is embodied in all software – regardless of how insignificant,” said the master.
“Is the Tao in a hand-held calculator?” asked the novice.
“It is,” came the reply.
“Is the Tao in a video game?” continued the novice.
“It is even in a video game,” said the master.
“And is the Tao in the DOS for a personal computer?”
The master coughed and shifted his position slightly. “The lesson is over for today,” he said.
From The Tao of programming – Chapter 4: Coding
Moral of the story (Score:1, Insightful)
Re:I have a saying (Score:3, Insightful)
Batch scripts are for very simple operations - it's literally just command line commands all at once (rather in order, as though they were one command). All of the methods implemented in batch are actually implemented in the DOS command prompt, the script just executes it as though you had punched it into a command prompt.
What this means is, if you've been using DOS for a very long time, and know the commands and syntax backwards and forwards, there is no simpler tool on the planet for a job a batch script can handle than a batch script. It is virtually 1:1 for entering commands into a command prompt. It has very minor extended functionality, which is what makes it so doggone easy to use.
As you've pointed out, there are a number of things batch cannot do, for exactly the reasons I gave for its ease of use. But, if a batch program does what you need, why in god's name would you use anything more complicated than that?
I actually ask questions at interviews to try to find people with your philosophy and weed them out.
And you're a fool for doing so, particularly because you don't understand the GP's philosophy at all. He's applying basic engineering concepts, like Keep It Stupid Simple, and you're weeding him out because he doesn't use whichever useless design paradigm flavor of the month you prefer.
The fact that you'd rather he write a whole complicated program to do the job instead of a simple script, without knowing how such an app is going to be used by his customers, just screams idiot to me. More complicated is never, ever better. Assuming you can do the exact same thing with something simpler, at the very least you've wasted time and effort by choosing the more complicated option. I don't know who told you batch scripts were hard to maintain, there is literally nothing to maintain. They are command line commands. If it works in the command line it works in the batch script. /? is your friend, and a lot more helpful than anything you'll get in even the best IDE's.
That said, depending on who the customer is (he could be using corporate speak for individuals within his company, we use the term as well), and how often they would want to use this, an application could be warranted. If his customers are regular-joe consumers, they're probably not going to use the app at all, in which case you're probably leaving the tool for PC repair folks, so a batch script is a really good idea. The repair guy will be able to tell immediately what the script does and understand what information it's giving him. If your customer is some other department in your company whose end users may or may not need to run it often, then I'd build a simple app to do the job.
Basically, if it's for the IT guys, the script is more helpful. If it's for the end users, an app looks much more professional. There are various options between scripts and apps that you can use depending on how much effort this warrants.
Re:DOS Is dead use visual basic (Score:4, Insightful)
There's nothing wrong with cmd files. Some very advanced things are built using them.
HFslip [hfslip.org] - hotfix slipstreamer.
BATCH is a good quick&dirty tool, for quick&dirty jobs. Right now I'm using cmd files to manage cmdline folding clients. They're installed as services, but they start up faster than everything else, and then slow down other stuff loading. Now, thanks to my quick and dirty batch scripting, they get started after everything else. (on XP) With a single command I can toggle them off so they don't come on after a reboot, which is handy if I was rebooting to play a game.
I considered using Java, but it's just not worth the time. It took 2 minutes to write the first script in batch, and less than 20 minutes to refine it.
Re:DOS Is dead use visual basic (Score:5, Insightful)
It sounds to me like the current implementation is not only effective and clever, but is (Windows) version-independent, and doesn't require any installation of third-party tools or utilities.
Dude, you've created the Holy Grail of software. Why are you looking for alternatives?
Re:If you do use VB... (Don't do that!) (Score:3, Insightful)
Ouch! Last thing needed when distributing printer test code is another wrapper layer that could interfere with printing.
Except maybe an additional patch to turn off the additional wrapper layer, assuming it actually does that completely, every time no matter what... maybe that is really the last thing needed.
If .bat files won't do it for you, then you could look into the Windows implementation of Perl, coupled with the Tcl/Tk module, which gives you basic GUI support so you can fancy it up with buttons and input boxes and such. After you've got the script working right, you can run it through Perl2Exe or one of the other available compilers and distribute your work as a .exe file. This has two obvious advantages:
A very important side effect is that you'd gain a little experience with Perl, which can work scripting wonders that .bat files could never do.
Sort of a caveat: I once made my living by writing simple perl scripts that pulled data from the text dumps of a legacy MUMPS database and returned .csv files that the QA guys could play with in Excel. So I'm biased. I've also left the Microsoft ecosystem for Linux, since I think the Microsoft ecosystem is terminally polluted on its own effluvium. So I'm really, really biased. (Perl is FOSS originating in the Unix/Linux world; Perl2Exe is shareware that I remember cost under $50)
Re:DOS Is dead use visual basic (Score:3, Insightful)
***I would say that whatever method that works for you is fine.***
Absolutely. Provided that the numerous peculiarities of Microsoft's command language aren't an issue (will the users ever see the inards?), and you don't have to support Unix, why would anyone not use a scripting tool that requires no additional run time be installed?
Re:DOS Is dead use visual basic (Score:3, Insightful)
Have you looked at VB.net or C#.net?
It's not simple anymore. VB6 was the last "simple" vb.
Honestly, he should just jump to a real language as it will take the same amount of effort to get up to speed in C++ as it does to get up to speed in a inferior language like VB.net
Actually for rapid development right now Delphi is the new king in Rapid and easy design for simple apps like this. I was a VB6 guru, when VB.net and C#.net came out I started learning it and started dabbling in delphi. I was up to speed in delphi way faster than VB.net...
Less effort spent getting things going if he looks at delphi instead.
Re:DOS Is dead use visual basic (Score:5, Insightful)
Hardly a cardinal sin. I've made a few in my day with loops and multiple choices using labels and gotos and such. Declare all important variables upfront, comment reasonably, and give it the same amount of testing as you would in a "real" language. The fact that batch files have no dependencies is a pretty good advantage, and the interpreter is backwards compatible.
Shell scripts under *nix may be more functional, but batch files are perfectly serviceable, as long as you don't go on insane writing sprees with them.
Re:DOS Is dead use visual basic (Score:5, Insightful)