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:
  • by Joe The Dragon (967727) on Wednesday May 26, 2010 @06:36PM (#32354448)

    DOS Is dead use visual basic

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

      DOS is dead, and no-one cares
      If there is a shell, I'll see you there

      • Re: (Score:3, Insightful)

        by Anonymous Coward

        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

    • Re: (Score:3, Insightful)

      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.

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

        • Re: (Score:3, Insightful)

          by Lumpy (12016)

          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

      • by Eth1csGrad1ent (1175557) on Wednesday May 26, 2010 @09:06PM (#32356244)

        Yeah. VB, C++, Java, they all do PCL commands.

        ..but will it fit on a floppy ??

      • 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 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.
    • by game kid (805301) on Wednesday May 26, 2010 @06:41PM (#32354494) Homepage
      Visual Basic sucks. Get Firefox instead.
    • He's right. (Score:3, Informative)

      by Anonymous Coward

      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!

      • Re:He's right. (Score:4, Informative)

        by Anonymous Coward on Wednesday May 26, 2010 @07:14PM (#32354870)

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

        • Re:He's right. (Score:5, Informative)

          by kelsey.grammer (83287) on Wednesday May 26, 2010 @08:45PM (#32355994)

          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. (Score:5, Informative)

            by teridon (139550) on Thursday May 27, 2010 @07:54AM (#32360238) Homepage

            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.

      • Re: (Score:3, Informative)

        by Machtyn (759119)
        I disagree. Use Tcl/Tk, Perl/Tk, or any other cross OS scripting language that contain a graphical toolkit. Using Tcl/Tk at my last job, I was able to create some nifty little utilities with a GUI, and I didn't have to worry about compiling. I also didn't have to install Tcl/Tk on each computer that was going to use it, as I used a wrapper to put it together for release.

        I still used the command shell fairly extensively when it was needed and I used C# when it was called for. Right tool for right job a
    • by v1 (525388) on Wednesday May 26, 2010 @06:45PM (#32354572) Homepage Journal

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

      • Re: (Score:3, Interesting)

        by codepunk (167897)

        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.

      • by i.r.id10t (595143) on Wednesday May 26, 2010 @07:48PM (#32355274)

        I agree, if you are stuck on ms stuff then VB becomes your "shell scripting" language of quickness.

        This being /. though, I'll have to mention a small customized LiveCD (think DSL sized) with a (perl script | python script | brainfuck implementation | emacs extension | vi/vim script | whatever) with i/o to the user being prettified by some shell/exec stuff with zenity or by developing a graphical app using qt/gtk/whatever. Distribute as a business card cd or a bootable usb key. Have the marketing dept come up with some video, etc. to put on it, make it a bigger CD.

    • If you do use VB... (Score:5, Informative)

      by transporter_ii (986545) on Wednesday May 26, 2010 @07:11PM (#32354844) Homepage

      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 [tek-tips.com]

      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 [microsoft.com]

      • 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

    • 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 KevMar (471257) on Wednesday May 26, 2010 @07:28PM (#32355054) Homepage Journal

      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.

    • by Homr Zodyssey (905161) on Wednesday May 26, 2010 @08:25PM (#32355760) Journal

      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.

  • perl? (Score:4, Informative)

    by FooAtWFU (699187) on Wednesday May 26, 2010 @06:38PM (#32354452) Homepage
    There's Windows ports of Perl, both Cygwin and ActiveState, last I checked.
    • Re:perl? (Score:5, Interesting)

      by steveg (55825) on Wednesday May 26, 2010 @06:40PM (#32354470)

      Even better Strawberry Perl [strawberryperl.com]

      • 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.
        • Re:perl? (Score:5, Informative)

          by BJ_Covert_Action (1499847) on Wednesday May 26, 2010 @06:53PM (#32354630) Homepage Journal
          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 [cpan.org] 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.
          • Re: (Score:3, Interesting)

            by Anonymous Coward

            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.

        • Re: (Score:3, Funny)

          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.

          That's the first time I've heard Perl and better readability together.

    • Re: (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.

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

  • 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.
  • Powershell (Score:5, Interesting)

    by Shados (741919) on Wednesday May 26, 2010 @06:42PM (#32354516)

    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.

    • Re: (Score:2, Informative)

      If DOS made you happy, then Powershell could drive you to orgasm if you let it. Object-oriented scripting that can tap into .NET, WMI, COM objects, Windows APIs, and still read/replace part of a text file in one line. You will have to install it on older clients, but what you want can be done with Powershell 1.0, which is like 2MB.
    • It is integrated in the OS. I mean, it's part of Win7 and Win2008 R2.

  • by jgritty (1820240) on Wednesday May 26, 2010 @06:42PM (#32354520)
    Python would be my first choice.
  • Python (Score:3, Informative)

    by bmecoli (963615) on Wednesday May 26, 2010 @06:42PM (#32354524)
    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)
    • Re: (Score:3, Informative)

      by lmpeters (892805)

      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)

      Python also has a built-in "unittest" module that might make it a lot easier to manage your various test cases. I'd say if you can't count all of your test cases on one hand, you should take a serious look at that module.

  • AutoIt? (Score:5, Informative)

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

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

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

  • by UTF-8 (680134) on Wednesday May 26, 2010 @06:43PM (#32354548) Homepage

    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 [microsoft.com]

  • Okay (Score:4, Funny)

    by srwalter (39999) on Wednesday May 26, 2010 @06:44PM (#32354550) Homepage Journal

    You're crazy.

    • Exactly. I've programmed in dozens of programming languages and DOS shell scripting is the only one that made me want to scratch my eyes out with a fork. There are incompatibilities between versions, as in useful functionality was taken out. Why would you do this, Microsoft? Why? It was, frankly, my most miserable (real) programming experience.

      Still, it did what I needed it to do, after everything. So I would probably do it again if I had to.
  • by decipher_saint (72686) on Wednesday May 26, 2010 @06:44PM (#32354554) Homepage

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

  • by schmidt349 (690948) on Wednesday May 26, 2010 @06:44PM (#32354562)

    Are DOS Batch files too 1990s to be taken seriously in 2010?

    Is Ed "Too-Tall" Jones too tall?

  • dig your boldness (Score:3, Informative)

    by Crackez (605836) on Wednesday May 26, 2010 @06:44PM (#32354568)

    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.

    • Re: (Score:3, Informative)

      by kybred (795293)

      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.

      Be careful [cygwin.com] about that.

      I use Cygwin myself, but copying the .dll for use with your app is fraught with peril.

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

    • Well, your idea is a little bit complex to implement, but certainly more logical than using windows and batch files.

    • by lgw (121541)

      Seems like a decent idea, though you'd also need a system for replacing failed monkeys, motivating monkeys that are slacking, etc. Fortunately, there's an RFC that covers all of this [ietf.org].

  • by Anonymous Coward on Wednesday May 26, 2010 @06:49PM (#32354598)

    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: (Score:3, Informative)

      by rubies (962985)

      I second VBS - asking a customer to install Perl is just asking for trouble unless you're in Unix land. The reason Bourne shell is popular isn't because it's particularly good, but because you know it (or a close variant) will always be available on any *nix.

      VBS isn't particularly nice to program in, but if you know what you're doing you can call most windows functions and even do database queries if that floats your boat. Networking stuff is a breeze and you can do a dialog based GUI if necessary.

      • Re: (Score:3, Informative)

        by ImprovOmega (744717)

        The biggest advantage of VBScript is its easy exposure of practically all COM API's on the machine. This lets you run a ridiculous amount of automation tasks from VBScript, but you are horribly limited in the sense that it's really not an object oriented language. It lacks ability to do pointers and even structs (C-style structs that is) making any kind of advanced data structures cumbersome to implement. But for scripting it's leaps and bounds above batch files *shudder* so I have to give it a nod for t

    • by shutdown -p now (807394) on Wednesday May 26, 2010 @07:49PM (#32355294) Journal

      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: (Score:3, Funny)

      by forkazoo (138186)

      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.

      You can just make an exe out of a python script which collects the runtime and all dependencies into a single file. I'd want to do that before resorting to invoking VB. I guess if it is an all-MS shop locked in some sort of hellish time vortex (which is consistent with the OP asking about batch files) then they may keep enough Eye of Newt and pen

  • 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: (Score:3, Informative)

      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.

      What complexity does python add (for instance)? From the user's standpoint, if the .py file is associated with python (and it will be), double-clicking on the icon will run just like a batch file. And as pointed out, python can execute system commands too.

      I can see wanting to avoid cygwin, but python's a breeze.

      • Re: (Score:3, Informative)

        by Nitrodist (1791378)

        I can see wanting to avoid cygwin, but python's a breeze.

        Except for the fact that python run-time libraries aren't included with Windows, yeah, great.

    • by Jaime2 (824950)
      DOS batch files make reusing scripts very difficult. Pretty much anything else is better. The lack of a function or subroutine construct is its biggest downfall. This can quickly lead to cut-and-paste hell or a pile of work-arounds that makes the scripts almost impossible to maintain.

      BTW, your quote:

      If it's stupid and it works, it's not stupid.

      ... is pretty much the opposite of how professional programmers feel. My philosophy is that any idiot can keep banging on the keyboard until it works. It takes a reasonably competent programmer to make it

      • Re: (Score:3, Insightful)

        by Bigjeff5 (1143585)

        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 scrip

  • by Anonymous Freak (16973) <prius@driver.mac@com> on Wednesday May 26, 2010 @06:58PM (#32354686) Journal

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

    • Re: (Score:3, Interesting)

      by Jaime2 (824950)

      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.

  • I recommend bash or csh..
  • 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?
  • I don't think you will get good feedback unless you explain the following:

    (1) be simple - To your users? Is your current UI simple enough for them? Tip: If you know your user's names, you're the real interface.
    (2) be easy to update - Over a network or sneakernet? Do you have Admin rights? A central server?
    (3) be able to send PCL commands to LAN-attached printers - Seems detailed enough. Firewall might be a problem.
    (4) allow email feedback - Again, What's your firewall situation? POP/etc gets blocked a

    • by pclminion (145572)

      (3) be able to send PCL commands to LAN-attached printers - Seems detailed enough. Firewall might be a problem.

      I don't see why it would be, since PCL is what is typically sent to those printers normally.

  • You *could* keep using batch files, but you're missing out on the ability to really structure your code, you're missing out on nice libraries that can handle some stuff you'd otherwise need to write yourself, and you lose the ability to easily do reasonable data manipulation. I was initially inclined to just suggest Perl (it's what I use), but really any of the three would be just fine. Batch file programming is too limiting - I'm sure you have at least some inclinations towards this as you're asking /.

  • For automated development tasks I would go with "continuous build systems", such as Cruise Control (I mention it since I use this). Cruise Control comes in both Java and .Net varieties. The best thing to do is to decide what sort of development environment you have and choose the best tools to support them. I can't say how well Cruise will fit into an environment where C/C++ is the intended language, so if anyone has alternatives to suggest please mention them.

    While I do mention these are target for buildin

  • by wiredlogic (135348) on Wednesday May 26, 2010 @07:12PM (#32354848)

    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.

  • by TiggertheMad (556308) on Wednesday May 26, 2010 @07:21PM (#32354966) Homepage Journal
    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?!?"
  • But yeah, go buy yourself a good Powershell book. Assuming your environment is running XP at least, pushing out support for it is pretty much just an MSI install. Week or two playing around with it, and chances are you'll have a script that runs circles around your old one.

  • As you seem to be a MS fan, I can't believe you didn't consider dotNet languages and Silverlight.

    My personal favorite is VB.Net.
    Massive executables are the best way to show that your tool is of professional quality.

    Silverlight is of course necessary for any kind of interface.
    If you want to avoid a Web interface, use XAML.

    Hey, we are in 2010 !

  • Autohotkey (Score:3, Interesting)

    by gad_zuki! (70830) on Wednesday May 26, 2010 @07:27PM (#32355040)

    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.

  • I've been surprised more than once by the "richness" of DOS commands and options and what not, but it still blow chunks for not treating stdio and that ilk like as a file ala Unix and family, and getting user input for those interactive moments is impossible without resorting to tricks or a com objects or a simple cmd line app. Simply installing a perl interpreter takes care of all this and more. You could even install cygwin and have some measure of sanity in your testing.
    • Batch files are the lowest common denominator for a fairly large percentage of computers out there. The reason I often stick with them and VBScript is not because they're any damned good (they're not, batch files and VBScript are both crap for different reasons) but simply because I can pretty much guarantee they'll run on any Windows machine built in the last decade. I'm working on a network that has a mix of XP, Vista, Server 2003 and yes, one Windows 2000 machine, and despite their obvious limitations,

  • a multinational printer company that specializes in custom printing solutions for systems both modern and that date 15 years back... i suggest you take a look at BSD or Linux.
  • You can whip up a quick GUI with Ruby and WxRuby, and when you're happy with it, create a single executable file with rubyscript2exe. I see two problems: files tend to be large (~10MB) and thus a bit slow to run, but once running they're quite snappy. Ruby is a very easy language and WxRuby is also quite easy to use (not to mention cross-platform but I guess that's not high on your wish list).

Mirrors should reflect a little before throwing back images. -- Jean Cocteau

Working...