Forgot your password?
typodupeerror
Programming Windows

For Automated Testing, Better Alternatives To DOS Batch Files? 426

Posted by timothy
from the run-them-under-wine dept.
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."
This discussion has been archived. No new comments can be posted.

For Automated Testing, Better Alternatives To DOS Batch Files?

Comments Filter:
  • You are... (Score:1, Insightful)

    by Anonymous Coward on Wednesday May 26, 2010 @06:39PM (#32354466)

    Crazy.

  • by Monkeedude1212 (1560403) on Wednesday May 26, 2010 @06:40PM (#32354482) Journal

    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.

  • 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 [microsoft.com] gives you any advantages (probably not). You're in a different world than I so that last suggestion may be off the mark.
  • by jgritty (1820240) on Wednesday May 26, 2010 @06:42PM (#32354520)
    Python would be my first choice.
  • Re:perl? (Score:5, Insightful)

    by BJ_Covert_Action (1499847) on Wednesday May 26, 2010 @06:50PM (#32354614) Homepage Journal
    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.
  • by NFN_NLN (633283) on Wednesday May 26, 2010 @06:52PM (#32354622)

    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)

    by buss_error (142273) on Wednesday May 26, 2010 @06:56PM (#32354674) Homepage Journal

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

    by digitalunity (19107) <digitalunity.yahoo@com> on Wednesday May 26, 2010 @06:58PM (#32354684) Homepage

    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.

  • 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.)

  • by fuzzyfuzzyfungus (1223518) on Wednesday May 26, 2010 @07:01PM (#32354730) Journal
    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?
  • by buchner.johannes (1139593) on Wednesday May 26, 2010 @07:23PM (#32354990) Homepage Journal

    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.

  • by Rob the Bold (788862) on Wednesday May 26, 2010 @07:29PM (#32355060)

    nobody cares what you think.

    I dunno. At least one guy cared enough to respond.

  • by Bigjeff5 (1143585) on Wednesday May 26, 2010 @08:56PM (#32356120)

    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.

  • by Anonymous Coward on Wednesday May 26, 2010 @09:05PM (#32356242)

    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)

    by nicknamesarefunny (1810810) on Wednesday May 26, 2010 @09:25PM (#32356448)
    Moral of the story.... Never ask slashdotters something which begins like 'Which programming laguage should I use..." Chances are no one cares what the original problem is, but everyone will start bitching about how their 'programming language' is the most elegant one and can solve any problem under the sun! Your program works, is maintainable and does what it is supposed to do. You already are using the best solution! Others may not like it because they may think X programming is the real mans programming language. fcuk them!
  • Re:I have a saying (Score:3, Insightful)

    by Bigjeff5 (1143585) on Wednesday May 26, 2010 @10:36PM (#32357152)

    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.

  • by BikeHelmet (1437881) on Wednesday May 26, 2010 @11:04PM (#32357374) Journal

    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.

  • by SpectreBlofeld (886224) on Wednesday May 26, 2010 @11:11PM (#32357418)

    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?

  • 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:

    1. a .exe file looks a helluvalot more impressive than a .bat file
    2. you won't need to worry about someone messing around in your .bat and causing you needless support headaches.

    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)

  • by vtcodger (957785) on Thursday May 27, 2010 @07:07AM (#32359988)

    ***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?

  • by Lumpy (12016) on Thursday May 27, 2010 @08:07AM (#32360336) Homepage

    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.

  • by fbjon (692006) on Thursday May 27, 2010 @09:09AM (#32360906) Homepage Journal

    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.

  • by Random BedHead Ed (602081) on Thursday May 27, 2010 @11:23AM (#32362640) Homepage Journal
    I'm surprised no one has suggested the most obvious upgrade path from the DOS batch file, Windows PowerShell [microsoft.com]. It's the intended replacement for batch files, and basically looks like Perl, but a little more Windowsy. It's integrated with lots of .NET goodies and ActiveDirectory, but in many ways it will be familiar to DOS scripters.

Shortest distance between two jokes = A straight line

Working...