Slashdot Mirror
For Automated Testing, Better Alternatives To DOS Batch Files?
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."
DOS Is dead use visual basic
Even better Strawberry Perl
Ignorance killed the cat. Curiosity was framed.
I don't know who your customers are ... is this a sort of IT mass production heavy printer thing you're producing? I'm guessing so if they're LAN printers but who knows? Anyways if you're shipping this thing to residences, give the tool to your parents or -- failing that -- someone age ~15 or ~65. Give them the documentation you have and do not say a word. See what they do with it and how intuitive it is to them and take notes while they're using it. Do they successfully test the printer or fail? If they fail, that's actually your failure. So know your audience and maybe rethink the tool. But assuming that your audience isn't afraid of a command line interface, go for it. I guess you could look into whether or not Powershell gives you any advantages (probably not). You're in a different world than I so that last suggestion may be off the mark.
My work here is dung.
The modern way of doing shell scripting in Windows is now powershell, and most things are quickly moving toward that. Its not as integrated in the OS, but its damn close, and in many ways its better than alternative scripting languages (object piping instead of text piping, for example).
Now if its the best thing for your requirement? I don't know. But if you're planning to stick to shell scripting, do yourself a favor and upgrade.
Python would be my first choice.
Its a great tool thats free, and has good GUI and has good scripting capabilities too:
http://www.autoitscript.com/autoit3/index.shtml
Python is much easier to write and much more maintainable than a batch script. Unfortunately it can be unfeasible to require this dependency on Windows machines.
Good dependency-free (albeit platform-specific) alternatives are .vbs (visual basic script) and .js. Both allow access to more modern dialog boxes etc. Either script should be executed under wscript.exe (windows scripting host) but I believe there is an automatic file association by default (at least for .vbs files).
For a more modern alternative, try Powershell, however it is only present by default on Windows 7.
I'll second this one. The place that I work runs almost all of its commands via bat jobs that run from simple to complex. When I started here, I installed Strawberry Perl on my win32 system. I have, since, replaced every functionality that the bat jobs used to do with perl scripts (primarily for my own purposes, but most of my coworkers don't mind them either). The primary reason I did this was readability. I can set up my perl scripts in such a manner that I can look at them a year later and know exactly what I did and how I did it. All I had to do was be a little disciplined about script formatting and variable names (it's really not that hard).
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.
Motorcycles, Robots, Space Gossip and More!
Oh, I should caveat one thing. In order to develop perl scripts into a distributable, platform independent, one click executable, I've been using the PAR packager module for perl. Sometimes it produces slightly bloated .exe's (since it has to bring in all of the relevant code from any external modules and dependencies), but it seems to produce very stable executables on win32 systems.
Motorcycles, Robots, Space Gossip and More!
"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.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
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.)
Another non-functioning site was "uncertainty.microsoft.com."
The purpose of that site was not known.
Why would you consider messing with something that works?
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?
Did some quick research on it and it does look like it would work. But I did find this information:
http://www.tek-tips.com/viewthread.cfm?qid=655463&page=6
Doctors destroy health, lawyers destroy justice, universities destroy knowledge, religion destroys spirituality
AutoHotKey or AutoIt are better and they are free unlike Visual Basic.
I would also look to Powershell to solve his issue.
Before Powershell, I would have went with VB Script.
Because he was wanting a bit more of a GUI, HTA (HTML Application) would be a simple option. It is a local web page named .hta instead of .html and it runs with application security on the local computer. Any script you can put in a .vbs file, you can also put into a script block of a .hta. This is one of those little tricks that not to many people know about.
I use hta when I want to keep the flexibility of html/script as an alternative to a compiled vb.net app.
Im a gamer, not a grammer major. This post is full of spelling and grammer mistakes.
AutoHotKey or AutoIt are better and they are free unlike Visual Basic.
Mod this up. I've used C++, Java, Perl, Ruby, vbscript, batch, and likely a few more to do this kind of thing in Windows over the years. For something this small I haven't found anything that beats AutoIt. It's so easy to learn and is fantastic for creating small, standalone executables with a GUI on Windows. This task is a perfect fit.
I reflect your pompous signature back upon you.
AutoIt is nice -- the first time. That's how they hook you.
Then, a year later, you decide to update your program. And hey, why not update to the latest version of AutoIt while you're at it? There was this one bug that always annoyed you, and you hope the devs fixed it.
Well, guess what? While you had your back turned, all the APIs for the GUI changed. All those calls you made to AwesomeFunction() now require 4 arguments instead of 3. Oh, and one of them is now an object instead of string.
That was my personal experience, anyway. After wroting a GUI program with perhaps 3000 lines of code, I updated to the new version of AutoIt. It seemed I had to practically rewrite the entire thing. Since then, I haven't recommended AutoIt to anyone that I like.
I hold it, that a little rebellion, now and then, is a good thing. -- Thomas Jefferson