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
There's Windows ports of Perl, both Cygwin and ActiveState, last I checked.
The World Wide Web is dying. Soon, we shall have only the Internet.
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.
Python is my scripting language of choice because it's easy to use and it has it's own "os" module that you can use to launch commands and the like, not to mention the "glob" module, which can grab all file names in a given directory into an array. I highly recommend it. (2.6)
Its a great tool thats free, and has good GUI and has good scripting capabilities too:
http://www.autoitscript.com/autoit3/index.shtml
DOS batch files has too many limitations when compared to other scripting languages. It's frozen in time. I consider Windows PowerShell to be the batch file successor.
http://technet.microsoft.com/en-us/scriptcenter/powershell.aspx
You're crazy.
Freedom is the freedom to say that 2 + 2 = 4
Not sure why batch is such a bitch, but you can execute shell commands with Ant.
crazy dynamite monkey
Is Ed "Too-Tall" Jones too tall?
For Windows platforms, there's nothing better for rapid prototyping than VB.NET - or really any of the .NET languages. Plus, you can get a version of Visual Studio from Microsoft for free that will do everything you want. Plus, you definitely won't regret having VS as a debugging environment.
Think of how happy your customers will be to interact with a modern-looking app that only took you a few hours to put together!
must be nostalgic for you or something...
If it were me, I would put together what you need to work with Cygwin, then it could be cross platform. You could even ship a copy of cygwin.dll and any binaries you need, like bash, netcat, or what have you. I prefer Unix apparently.
I believe the only sensible and practical idea here is to have 1000 monkeys at 1000 consoles doing these automated tasks for you. Of course you'd need to feed these monkeys, so you'd need more monkeys. Thus, 1000 monkeys at 1000 banana plantations.
"I'm going to f***ing bury that guy, I have done it before, and I will do it again. I'm going to f***ing kill Google"
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.
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.
DOS sounds like "Boss" not like "dose".
Give me Classic Slashdot or give me death!
"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
You could consider VB Script and HTML wrapped into a WSH file if you want a simple web GUI and being locked to IE isn't a problem.
I am becoming gerund, destroyer of verbs.
I am working on a project that would allow our customers to test our sending different PCL commands to LAN printers.
I will be looking forward to the first error is encountered by a user. You will hear someone in the cubical farm say, "PCL PC Load letter? What the fuck is PCL PC Load letter?!?"
HA! I just wasted some of your bandwidth with a frivolous sig!
I guess everyone has their favorite scripting language and I'm sure Powershell is awesome, but it came 10 years too late. I'm personally fond of Autohotkey. Its a decent scripting language, has lots of handy built in functions, and is easy to pick up, especially for those of us who don't code everyday. I'm always a little surprised at how much it can do. I've used it to manipulate installers with no command line options by using the built in functions to grab the GUI window, press buttons, etc. Most everything it can't do I can do in Windows by putting the unixutils on a share and just calling them via the script. Granted, its a work-around but it works for me.
Wizard? Pfft!
He needs to re-implement Clippy!
Think of how helpful this would be :)
...
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.
The other posters are correct. You only say "DAHS" if you're from Boston, as in: "Oh My Gawhd, some retahd on slashdaht is still writing DAHS bahtch files. Why don't we just fihre up Windows fah Workgroups while we're aht it."
Seriously though - I think nmap can send PCL commands via the nmap scripting engine, which is written in LUA. How about wrapping that with what some of the other posters are suggesting?
That's me Perl hardcore programmer saying.
If your Perl code is anything like your sentences...oh, who am I kidding, it would still make more sense than MY Perl code.
You can use bash on most Linux implementations
You're in luck: there is something better than being a trolling twat making useless suggestions. It's called "sticking your head in a vise."
What you do is get a vise, you put your head in it, and you twist the handle until it contacts both sides of your head. At this point you'll really have to turn the handle hard, but keep going.
You can stick your head in a vise in most wood shops.
I write Perl largely like I learned to write C, so its very readable, though perhaps not particularly idiomatic.
woorsh?
http://search.cpan.org/~karasik/Win32-GuiTest-1.56/lib/Win32/GuiTest.pm
Perl has plenty of Windows-specific modules made for this type of application.
Yeah. VB, C++, Java, they all do PCL commands.
..but will it fit on a floppy ??
I never heard anyone say it.
Ugh. Now I feel old. Screw you, AC.
Most electronics companies where I've worked or consulted use LabVIEW for automated product testing.
You can download an eval copy from http://www.ni.com/labview/optin/trylabview
LabVIEW is graphical programming. I'm still loyal to C/C++, but all those text languages are so 20th century! ;) Until we achieve natural language programming, LabVIEW is as good as it gets for 21st century.
Putting humor aside, LabVIEW apps are very simple to write and deploy. The Application Builder allows you to create an EXE from your app and bundle it with the runtime in a nice Windows installer that you can send to your customers.
I've seen some suggestions on here for PowerShell. One limitation of DOS batch files is the inability to interact directly with .NET. Anyone on modern Windows should learn .NET since it is the preferred framework now for that OS. PowerShell can give you the .NET access, but LabVIEW will have a much quicker learning curve if you ever have the urge to delve into .NET.
The LabVIEW forums are very active, and the community gurus provide quick turnaround on support questions. For long-term maintenance of your test app, you're likely to find more engineers in the Test&Measurement arena that use LabVIEW versus DOS.
Good luck in your choices!
A "friend" of mine used to always stick a copy of LoveDOS on anyone's computer in college that was left unattended. The ending comment of "Call me crazy but I love DOS" brought these "fond" memories back. It looks like someone has actually archived a copy of it, as well as putting together some screen shots and info about it: http://jeff.rainbow-100.com/?p=100 Ever since being inflicted with LoveDOS I have set up every computer I own to use a BIOS password.
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)
Will
Where I work, we have used Python to create a regression and qualification testing framework for embedded avionics software. It has worked out exceptionally well. The testing framework was originally developed on Windows, but we are also porting it to Linux. (The Python parts are completely portable, of course... but because of the nature of the application we also had to create libraries in C to drive some specialized hardware, and the C modules do require some porting effort.)