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

15 of 426 comments (clear)

  1. Re:perl? by steveg · · Score: 4, Interesting

    Even better Strawberry Perl

    --
    Ignorance killed the cat. Curiosity was framed.
  2. Re:perl? by CrimsonAvenger · · Score: 2, Interesting

    There's Windows ports of Perl, both Cygwin and ActiveState

    Which pretty much blows a hole in the "single file" concept, since you'd need to include the Perl installations, and update same from time to time.

    --

    "I do not agree with what you say, but I will defend to the death your right to say it"
  3. Windows Powershell by Anonymous Coward · · Score: 1, Interesting

    Is a better scripting alternative imho.

  4. Powershell by Shados · · Score: 4, Interesting

    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.

    1. Re:Powershell by KibibyteBrain · · Score: 2, Interesting

      It is worse because it suddenly makes one of the proposed strengths of the *nix platform look obsolete, and this is Slashdot.

  5. Try Windows PowerShell by UTF-8 · · Score: 3, Interesting

    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

  6. Execute Shell commands with Ant by decipher_saint · · Score: 2, Interesting

    Not sure why batch is such a bitch, but you can execute shell commands with Ant.

    --
    crazy dynamite monkey
  7. Re:DOS Is dead use visual basic by codepunk · · Score: 2, Interesting

    No but now your folder of com files will require a butt load of runtime files on every single workstation. Now personally I would smack it out as a stand alone executable in delphi, but that is just me.

    --


    Got Code?
  8. You're serious.... by Anonymous Coward · · Score: 0, Interesting

    ... a DOS batch file was your *FIRST* thought?

    Wow... just, wow.

  9. Consider WSH if you want a simple web GUI by wiredlogic · · Score: 2, Interesting

    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.
  10. Re:perl? by Anonymous Coward · · Score: 3, Interesting

    You can cut the bloat by making the executables dependent on an external perl5lib.dll file. You can also factor out common libraries into separate PAR packages to be used by your executables. But this blows the whole point of bound exes in my opinion, and disk is cheap.

  11. Autohotkey by gad_zuki! · · Score: 2, Interesting

    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.

  12. Re:If .bat will do it, stick with .bat! by Jaime2 · · Score: 2, Interesting

    But DOS batch files still work just fine.

    I've found that UAC in Vista and Windows 7 hate batch files. Some of my old processes that are still batch file based fail silently on new operating systems. Suck it up and move into the 1990's at least.

  13. DOS no workie on 64 bit by Anonymous Coward · · Score: 1, Interesting

    Just in case someone else doesn't mention it....

    There is no 16 bit DOS subsystem in 64 bit Windows to run said BAT files. So your program will probably have a fairly short shelf life.

    You can run CMD files which are almost the same as BAT files though.

  14. LoveDOS by JimWise · · Score: 2, Interesting

    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.