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."

Comments

AutoIt?

[Anonymous Coward]

Its a great tool thats free, and has good GUI and has good scripting capabilities too:

http://www.autoitscript.com/autoit3/index.shtml

Re:DOS Is dead use visual basic

[v1]

+1 agree. VB is RAD (rapid application development), is very flexible, and is easy to use to make standalone apps. if you like programming in dos, you will love VB. For the use you are suggesting, it sounds ideal. you can basically have it be the gui front end for things you need to be done in dos (via vb, you don't need a folder full of com files for it to use)

Hate to say it... how about vbs?

[Anonymous Coward]

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.

Re:Hate to say it... how about vbs?

[shutdown -p now]

Indeed, Active Scripting with VBscript or JScript is the only alternative if it has to run without any extra dependencies. It's available as a stock component from at least Win2K (I believe it's actually Win98, but can't be bothered to check; and I'm certain about Win2K). And while VBScript is ugly, JScript is a rather decent interpreted implementation of Ecma-262, and has enough hooks to do the stuff that is required here. And it's infinitely better than DOS batch files, that's for sure.

Re:perl?

[BJ_Covert_Action]

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.

If you do use VB...

[transporter_ii]

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

But here's the problem.... usually, when you use the printer object in VB to print with, it puts MORE PCL code round what you send (or PostScript, depending on the driver you use) and that messes the whole thing up.

So one of my colleagues found a reference at MicroSoft on how to do what they call Raw Printng, which is direct to the printer not thru' the driver. We experimented with it and it does work. Here's the url: http://support.microsoft.com/support/kb/articles/Q154/0/78.asp

Re:He's right.

[Anonymous Coward]

AutoHotKey or AutoIt are better and they are free unlike Visual Basic.

Powershell or VB Script w/ hta

[KevMar]

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.

Re:DOS Is dead use visual basic

[Homr Zodyssey]

I often write stuff like this using javascript or vbscript, and run it with "cscript". Its included in WinXP and later, so there's no installation required -- just a js or vbs script file. So, it would function much like your Batch file but you'd have a more descriptive language to work with.

I do think vbscript is da debbil. However, it does have its uses when it comes to interacting with Office documents.

Re:He's right.

[kelsey.grammer]

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.

Re:He's right.

[teridon]

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.