Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

For Automated Testing, Better Alternatives To DOS Batch Files?

timothy posted more than 4 years ago | from the run-them-under-wine dept.

Programming 426

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

cancel ×

426 comments

Sorry! There are no comments related to the filter you selected.

DOS Is dead use visual basic (5, Funny)

Joe The Dragon (967727) | more than 4 years ago | (#32354448)

DOS Is dead use visual basic

Re:DOS Is dead use visual basic (5, Funny)

Anonymous Coward | more than 4 years ago | (#32354468)

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

Re:DOS Is dead use visual basic (2, Insightful)

Monkeedude1212 (1560403) | more than 4 years ago | (#32354482)

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.

Re:DOS Is dead use visual basic (5, Funny)

game kid (805301) | more than 4 years ago | (#32354494)

Visual Basic sucks. Get Firefox instead.

Re:DOS Is dead use visual basic (-1)

Anonymous Coward | more than 4 years ago | (#32355036)

Yeah, that's a great idea. So instead of distributing a 250-byte .bat file or a 10 KB .exe, he instead just has to deploy 75 KB of JavaScript, another 75 KB of XUL, and the 14 MB Gecko runtime.

Fuck, even Java managed to keep it down to only a 12 MB runtime, and 25 KB .class file.

He's right. (3, Informative)

Anonymous Coward | more than 4 years ago | (#32354564)

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. (4, Informative)

Anonymous Coward | more than 4 years ago | (#32354870)

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

Re:DOS Is dead use visual basic (4, Informative)

v1 (525388) | more than 4 years ago | (#32354572)

+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:DOS Is dead use visual basic (2, Interesting)

codepunk (167897) | more than 4 years ago | (#32354700)

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.

If you do use VB... (4, Informative)

transporter_ii (986545) | more than 4 years ago | (#32354844)

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]

Re:DOS Is dead use visual basic (5, Insightful)

buchner.johannes (1139593) | more than 4 years ago | (#32354990)

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.

Powershell or VB Script w/ hta (5, Informative)

KevMar (471257) | more than 4 years ago | (#32355054)

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 (-1)

Anonymous Coward | more than 4 years ago | (#32355086)

Visual Basic 1.0 is for DOS you insensitive clod!

Re:DOS Is dead use visual basic (-1)

Anonymous Coward | more than 4 years ago | (#32355216)

Visual Basic is dead too. If you are in a well-known environment and not deploying this as any solution, then perhaps something like ActivePerl, Python, or other script environment might work for you, IF you don't mind setting it up and maintaining and tinkering with it. If it is on a newer Windows NT box, there is PowerShell. Of, if you are up to it, you can opt for a general purpose language like Java, C/C++, or even C#. As an idea, if all you are doing is testing, consider writing a few unit tests in C# or Java, and use one of the many unit test automation utilities to run it (e.g. MbUnit/NUnit, VS Tests, JUnit). If your environment has traditionally been and is a MS one, then I'd opt for writing C# unit tests - they are super easy to write. If you may migrate to or are in a *nix shop, Java would be a prudent choice.

perl? (3, Informative)

FooAtWFU (699187) | more than 4 years ago | (#32354452)

There's Windows ports of Perl, both Cygwin and ActiveState, last I checked.

Re:perl? (4, Interesting)

steveg (55825) | more than 4 years ago | (#32354470)

Even better Strawberry Perl [strawberryperl.com]

Re:perl? (5, Insightful)

BJ_Covert_Action (1499847) | more than 4 years ago | (#32354614)

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? (5, Informative)

BJ_Covert_Action (1499847) | more than 4 years ago | (#32354630)

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:perl? (3, Interesting)

Anonymous Coward | more than 4 years ago | (#32355006)

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:perl? (0)

jsepeta (412566) | more than 4 years ago | (#32355186)

shouldn't you be documenting your code in order to remember what you did, why you did it, and how you did it many years hence?

Re:perl? (2, Interesting)

CrimsonAvenger (580665) | more than 4 years ago | (#32354484)

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? (2, Informative)

bi$hop (878253) | more than 4 years ago | (#32354518)

But do your users have perl installed? If not, you'll need to "compile" it (e.g. with ActiveState's Perl Development Kit). This actually works quite well, but it's more effort than a simple batch file.

That being said, if you've found the best tool for the job, why are you asking for ideas on slashdot?

Re:perl? (3, Insightful)

digitalunity (19107) | more than 4 years ago | (#32354684)

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.

Re:perl? (1)

dredawg (887707) | more than 4 years ago | (#32355110)

Cygwin and PERL are my vote as well.

You are... (1, Insightful)

Anonymous Coward | more than 4 years ago | (#32354466)

Crazy.

Re:You are... (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#32354896)

Found a trojan on the network that's been there for four FUCKING YEARS. Reinfection's all over the goddamn place, I am going into business, these fucking morons do not deserve my help therefore, I will FUCK EVERYONE OVER.

Ruby or Python (1)

AffidavitDonda (1736752) | more than 4 years ago | (#32354474)

I would have thought about Ruby or Python for that kind of work. Both are easy to learn, easy to install and you can write everything from a shell script to a fully featured application. But Visual Basic would work as well I guess...

Re:Ruby or Python (1)

bsDaemon (87307) | more than 4 years ago | (#32354938)

isn't Python the Visual Basic of the FOSS world?

Is it pronounced DOHS or DAHS? (0)

Anonymous Coward | more than 4 years ago | (#32354496)

I never heard anyone say it.

Re:Is it pronounced DOHS or DAHS? (1)

satoshi1 (794000) | more than 4 years ago | (#32354642)

DAWS.

Re:Is it pronounced DOHS or DAHS? (1, Funny)

Anonymous Coward | more than 4 years ago | (#32354952)

DAWS.

No, the S is soft as in "esss" not "zee". da "AWE" ssss

It's pronounced the same as the word "DAS" in German; the A is soft ("AAAH" not "OH")

So... "DAHS" is probably about right.

And since no decent /. Anon post is complete without some kind of rant:

The word is wash. Observe the letters, notice you have Waaaaaaaaaa and then sshhhhhhhhh.

  There is NO 'R' in wash.

  It is not pronounced WORSH otherwise it'd be spelled that way.
  It's not a regional accent, it's a complete mis-pronunciation of the word. Stop it already; it just makes you sound like you have a speech impediment. Or a single digit IQ.

Re:Is it pronounced DOHS or DAHS? (3, Informative)

Hatta (162192) | more than 4 years ago | (#32354654)

DOS sounds like "Boss" not like "dose".

iron? (0)

Anonymous Coward | more than 4 years ago | (#32354498)

ironpython ironruby?

Windows Powershell (1, Interesting)

Anonymous Coward | more than 4 years ago | (#32354506)

Is a better scripting alternative imho.

Is cygwin on the menu? (0)

Anonymous Coward | more than 4 years ago | (#32354508)

You mentioned that you'd like it to be self contained, but would you have access to cygwin?

A bash script is ANSI capable, you can call dos binaries, and you could also potentially take advantage of 'dialog' style interactivity:
http://www.hightek.org/dialog/screenshots.html

If It Works, It Works But Remember Your Customers (4, Insightful)

eldavojohn (898314) | more than 4 years ago | (#32354510)

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.

Re:If It Works, It Works But Remember Your Custome (3, Insightful)

NFN_NLN (633283) | more than 4 years ago | (#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.

Re:If It Works, It Works But Remember Your Custome (1)

NatasRevol (731260) | more than 4 years ago | (#32354846)

Wizard????

Did you see the freaking subject, much less the summary?

Re:If It Works, It Works But Remember Your Custome (2, Funny)

Barny (103770) | more than 4 years ago | (#32355052)

Wizard? Pfft!

He needs to re-implement Clippy!

Think of how helpful this would be :)

Re:If It Works, It Works But Remember Your Custome (1)

h4rr4r (612664) | more than 4 years ago | (#32354926)

A wizard?

are you out of your fucking mind?

Powershell (4, Interesting)

Shados (741919) | more than 4 years ago | (#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:Powershell (2, Informative)

isThisNameAvailable (1496341) | more than 4 years ago | (#32354802)

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.

Re:Powershell (0, Troll)

h4rr4r (612664) | more than 4 years ago | (#32354936)

Object piping is not better, it is worse.

Re:Powershell (0, Troll)

Anonymous Coward | more than 4 years ago | (#32355010)

The modern way of doing shell scripting in Windows is now powershell

No, the modern way of doing scripting in Windows is install Bash, Perl or Python. Powershell is to modern as cat is to dog.

Python would be my first choice. (4, Insightful)

jgritty (1820240) | more than 4 years ago | (#32354520)

Python would be my first choice.

Re:Python would be my first choice. (-1, Redundant)

Anonymous Coward | more than 4 years ago | (#32354716)

nobody cares what you think.

Re:Python would be my first choice. (3, Insightful)

Rob the Bold (788862) | more than 4 years ago | (#32355060)

nobody cares what you think.

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

As a perl geek I have to say... (1)

elFisico (877213) | more than 4 years ago | (#32354522)

use perl; # :-)

Perl is a much better scripting/programming language. You can even use Tk for a more windowy experience. And if you cannot do what you want to do directly in perl, you can still call a DOS batch file that does the windows-specific things...

Python (3, Informative)

bmecoli (963615) | more than 4 years ago | (#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:Python (2, Informative)

lmpeters (892805) | more than 4 years ago | (#32354666)

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.

Well, try the new model (0)

Cruise_WD (410599) | more than 4 years ago | (#32354532)

Powershell might be worth a look.

Admittedly, Microsoft's attempt to add proper shell scripting is pretty much what you'd expect from Microsoft - overly complex, inconsistent and monolithic, but it is pretty powerful.

AutoIt? (5, Informative)

Anonymous Coward | more than 4 years ago | (#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]

Re:AutoIt? (0)

Anonymous Coward | more than 4 years ago | (#32355184)

I'll second AutoIT. I've used to write some fairly complex push and/or pull build scripts in the past. The syntax is essentially the same as VB.

You can compile the scripts to standalone .exe (ie no run time etc required) making deployment easy - why not write a deploy script :)

If the script needs to reference password info then the compilation to .exe provides a basic protection from exposing the password to users, though it is trivial to decompile so don't rely on it for sensitive data protection.

User prompting is super simple from simple Yes/No/Cancel to text input prompts and file choosers.

Also useful for automation of apps that don't provide a decent API, via some nice UI manipulation functions (mouse and keyboard events). Quite a few game bots have been written with AutoIT.

powershell (0)

Anonymous Coward | more than 4 years ago | (#32354538)

i think microsoft is aiming for powershell to replace .bat files, BUT you'll need windows 7. I'm not sure if vista ships with power shell.....

Re:powershell (2, Informative)

digitalunity (19107) | more than 4 years ago | (#32354710)

It doesn't, but you can download it.

Try Windows PowerShell (3, Interesting)

UTF-8 (680134) | more than 4 years ago | (#32354548)

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

srwalter (39999) | more than 4 years ago | (#32354550)

You're crazy.

Re:Okay (1)

phantomfive (622387) | more than 4 years ago | (#32355126)

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.

Execute Shell commands with Ant (2, Interesting)

decipher_saint (72686) | more than 4 years ago | (#32354554)

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

15 minutes could save you... (3, Funny)

schmidt349 (690948) | more than 4 years ago | (#32354562)

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

Is Ed "Too-Tall" Jones too tall?

dig your boldness (3, Informative)

Crackez (605836) | more than 4 years ago | (#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.

Sensible Suggestion... (2, Funny)

Elitist_Phoenix (808424) | more than 4 years ago | (#32354576)

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.

Re:Sensible Suggestion... (1)

GNUALMAFUERTE (697061) | more than 4 years ago | (#32354762)

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

Re:Sensible Suggestion... (1)

lgw (121541) | more than 4 years ago | (#32355044)

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

Hate to say it... how about vbs? (5, Informative)

Anonymous Coward | more than 4 years ago | (#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:Hate to say it... how about vbs? (2, Informative)

rubies (962985) | more than 4 years ago | (#32355038)

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.

4DOS! (1, Informative)

Anonymous Coward | more than 4 years ago | (#32354632)

It was extended to 8.00 by Luchezar Georgiev[1], and supports REXX interpreter, including free ones[2].

[1] http://www.4dos.info/
[2] http://www.4dos.info/dalter.htm#08

I have a saying (5, Insightful)

buss_error (142273) | more than 4 years ago | (#32354674)

"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:I have a saying (2, Informative)

Mr. Underbridge (666784) | more than 4 years ago | (#32354944)

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:I have a saying (3, Informative)

Nitrodist (1791378) | more than 4 years ago | (#32355056)

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.

Re:I have a saying (0, Redundant)

masher_oz (1145983) | more than 4 years ago | (#32355072)

Yes, but you also require the user to have Python installed. I know that I don't have Python on my computer.

A Windows batch file requires you to have Windows installed. I know that I do have Windows though...

Re:I have a saying (0)

Anonymous Coward | more than 4 years ago | (#32355084)

The complexity is requiring the end-user to have Python installed.

Re:I have a saying (0, Redundant)

Rob the Bold (788862) | more than 4 years ago | (#32355192)

What complexity does python add (for instance)? .

Since I'm guessing this is a Windows environment -- installing Python. I wouldn't think it would be a big deal if the users were already installing the system being tested. But you did ask, and that is a slight increase in complexity.

Re:I have a saying (1)

Jaime2 (824950) | more than 4 years ago | (#32355130)

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 so that the next guy can understand it and maintain it. It takes a good programmer to make it so a new unanticipated feature can be added quickly without disturbing the system too much. I actually ask questions at interviews to try to find people with your philosophy and weed them out.

If .bat will do it, stick with .bat! (5, Insightful)

Anonymous Freak (16973) | more than 4 years ago | (#32354686)

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:If .bat will do it, stick with .bat! (1)

maxume (22995) | more than 4 years ago | (#32354920)

The people who make combofix have raised the bar for gnarly batch files. The exe is just a launcher and compressed blob of files. Inside the blob, there is more than 1 megabyte of batch files (a lot of it is just lists of files to check, but still).

Re:If .bat will do it, stick with .bat! (2, Interesting)

Jaime2 (824950) | more than 4 years ago | (#32355198)

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.

Use 'real' shells (1)

chipperdog (169552) | more than 4 years ago | (#32354712)

I recommend bash or csh..

Re:Use 'real' shells (1)

MichaelSmith (789609) | more than 4 years ago | (#32354766)

Or just the distributed version of DOS. I think it is called DDOS.

Assuming nobody is whining... (4, Insightful)

fuzzyfuzzyfungus (1223518) | more than 4 years ago | (#32354730)

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?

Another vote for Powershell... (0)

vistapwns (1103935) | more than 4 years ago | (#32354736)

Very powerful and clean language, it's installed by default on Windows 7, but you'll have to download for older Windows versions. Or if downloading/installing isn't an option for older OSes, there's vbscript...

More Details (1)

clinko (232501) | more than 4 years ago | (#32354738)

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 lot if they're (the app) is the "server".

Not gripes, just helpful to know if you want answers.

Re:More Details (1)

pclminion (145572) | more than 4 years ago | (#32354894)

(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're serious.... (0, Interesting)

Anonymous Coward | more than 4 years ago | (#32354772)

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

Wow... just, wow.

Batch works out of the box (0)

Anonymous Coward | more than 4 years ago | (#32354776)

I love my batch files in my domain, they dont get flagged by Antivirus or spyware programs like some of my vbs scripts. Work out of the box and dont require extra software to be installed.....

Perl, Python, or Ruby... (1)

Improv (2467) | more than 4 years ago | (#32354820)

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

Cruise Control and continuous build systems (1, Offtopic)

Midnight Thunder (17205) | more than 4 years ago | (#32354842)

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 building applications, many of these solutions include support for the unit testing phase of your projects.

Consider WSH if you want a simple web GUI (2, Interesting)

wiredlogic (135348) | more than 4 years ago | (#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.

Dont take my stappler. (2, Funny)

TiggertheMad (556308) | more than 4 years ago | (#32354966)

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?!?"

Others have already said it (1)

jayhawk88 (160512) | more than 4 years ago | (#32354980)

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.

.Net and Silverlight (1, Funny)

eulernet (1132389) | more than 4 years ago | (#32354984)

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 (2, Interesting)

gad_zuki! (70830) | more than 4 years ago | (#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.

DOS vs PERL (1)

interval1066 (668936) | more than 4 years ago | (#32355046)

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.

Re:DOS vs PERL (1)

MightyMartian (840721) | more than 4 years ago | (#32355214)

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, I know with reasonable certainty that keeping my login scripts and various other utility scripts in CMD.EXE batch and VBScript means I have little or nothing to worry about in the way of dependencies.

It's the reason I try to keep to fairly vanilla shell and Perl scripts on my *nix boxes, and avoid where I can going for more advanced features, simply because it too represents an LCM, and when you're dealing with heterogeneous networks, you need to consider portability.

Another underlying principle is KISS. If a batch script does the job, why go further? Is it necessary to install ActivePerl if you're just doing some basic menu processing? There's nothing inherently wrong with using the tools available to you, providing they work reasonably well and are reasonably supportable. I've seen too many guys get on the complicated-but-cool bus and end up with insanely complicated dependencies for basic scripting.

lotss of good suggestions (1)

amliebsch (724858) | more than 4 years ago | (#32355100)

But since nobody else mentioned it, let me suggest jscript wrapped in a wsh file. It,s built into windows, is one file and being text can be easily versioned.

Easy (0, Troll)

gyrogeerloose (849181) | more than 4 years ago | (#32355116)

Apple Script.

having worked for (1)

nimbius (983462) | more than 4 years ago | (#32355124)

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.

PowerShell + Windows Forms = Happiness! (0)

Anonymous Coward | more than 4 years ago | (#32355182)

Seriously, investigate PowerShell. I have yet to find a situation where I could not create a solution using this wonderful tool. To take things even further, mix Sapien's PrimalForms IDE and you have slick GUI's running your PowerShell commands!

Ruby + WxRuby + rubyscript2exe (1)

Roadmaster (96317) | more than 4 years ago | (#32355208)

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

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>