Slashdot Mirror
For Automated Testing, Better Alternatives To DOS Batch Files?
An anonymous reader writes "I am working on a project that would allow our customers to test out sending different PCL commands to LAN printers. My initial thought was that a DOS batch file will allow users to select some simple options, send the tests to printers, and even generate a small web page which, when launched from the batch file, will provide email feedback on the tool. This all worked. To spice it up I added some ANSI color commands to the menus, though the implementation of that may prove tricky without resorting to .COM files or forcing the load of the ansi.sys via the command.com shortcut. And this implementation goes against my initial idea that I want the entire thing to be contained in a standalone batch file. My questions are: Is there a better option for this? Are DOS Batch files too 1990s to be taken seriously in 2010? The application needs to (1) be simple (2) be easy to update (3) be able to send PCL commands to LAN-attached printers and (4) allow email feedback. I don't know what other programming language would allow this and be as simple. I tend to think that I have found the best tool for the job but if you have another idea let me know. Call me crazy but I love DOS."
DOS Is dead use visual basic
There's Windows ports of Perl, both Cygwin and ActiveState, last I checked.
The World Wide Web is dying. Soon, we shall have only the Internet.
Crazy.
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...
I never heard anyone say it.
ironpython ironruby?
Is a better scripting alternative imho.
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
I don't know who your customers are ... is this a sort of IT mass production heavy printer thing you're producing? I'm guessing so if they're LAN printers but who knows? Anyways if you're shipping this thing to residences, give the tool to your parents or -- failing that -- someone age ~15 or ~65. Give them the documentation you have and do not say a word. See what they do with it and how intuitive it is to them and take notes while they're using it. Do they successfully test the printer or fail? If they fail, that's actually your failure. So know your audience and maybe rethink the tool. But assuming that your audience isn't afraid of a command line interface, go for it. I guess you could look into whether or not Powershell gives you any advantages (probably not). You're in a different world than I so that last suggestion may be off the mark.
My work here is dung.
The modern way of doing shell scripting in Windows is now powershell, and most things are quickly moving toward that. Its not as integrated in the OS, but its damn close, and in many ways its better than alternative scripting languages (object piping instead of text piping, for example).
Now if its the best thing for your requirement? I don't know. But if you're planning to stick to shell scripting, do yourself a favor and upgrade.
Python would be my first choice.
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 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)
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.
[ cruise / casual-tempest.net / xenogamous.com / transference.org / quantam sufficit ]
Its a great tool thats free, and has good GUI and has good scripting capabilities too:
http://www.autoitscript.com/autoit3/index.shtml
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.....
DOS batch files has too many limitations when compared to other scripting languages. It's frozen in time. I consider Windows PowerShell to be the batch file successor.
http://technet.microsoft.com/en-us/scriptcenter/powershell.aspx
You're crazy.
Freedom is the freedom to say that 2 + 2 = 4
Not sure why batch is such a bitch, but you can execute shell commands with Ant.
crazy dynamite monkey
Is Ed "Too-Tall" Jones too tall?
For Windows platforms, there's nothing better for rapid prototyping than VB.NET - or really any of the .NET languages. Plus, you can get a version of Visual Studio from Microsoft for free that will do everything you want. Plus, you definitely won't regret having VS as a debugging environment.
Think of how happy your customers will be to interact with a modern-looking app that only took you a few hours to put together!
must be nostalgic for you or something...
If it were me, I would put together what you need to work with Cygwin, then it could be cross platform. You could even ship a copy of cygwin.dll and any binaries you need, like bash, netcat, or what have you. I prefer Unix apparently.
I believe the only sensible and practical idea here is to have 1000 monkeys at 1000 consoles doing these automated tasks for you. Of course you'd need to feed these monkeys, so you'd need more monkeys. Thus, 1000 monkeys at 1000 banana plantations.
"I'm going to f***ing bury that guy, I have done it before, and I will do it again. I'm going to f***ing kill Google"
Python is much easier to write and much more maintainable than a batch script. Unfortunately it can be unfeasible to require this dependency on Windows machines.
Good dependency-free (albeit platform-specific) alternatives are .vbs (visual basic script) and .js. Both allow access to more modern dialog boxes etc. Either script should be executed under wscript.exe (windows scripting host) but I believe there is an automatic file association by default (at least for .vbs files).
For a more modern alternative, try Powershell, however it is only present by default on Windows 7.
Give them the documentation you have and do not say a word
If your product requires a manual than your user interface sucks.
Add a wizard for common scenarios... anything but documentation that no one will read.
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
"If it's stupid and it works, it's not stupid."
There are plenty of doges you can use, perl, python, bash, and lots more. But all of them add a level of complexity to this that the batch file doesn't have. Which leads me to my second saying:
"If it's simple and it works, it's elegant."
Sounds like you've found an elegant solution to a problem. I'd stick with it if it works for you.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
PowerShell is the new Batch File Scripting, so if you need more power, learn PowerShell and use that. (I am assuming you're in a Windows environment where change of OS isn't an option.)
But DOS batch files still work just fine. In my last job at $major-hardware-vendor, we used DOS batch file-based menus all the time; because they were simple, they got the job done, and all the people who had any need to maintain them knew all about them. Some were particularly large/gnarly batch files, too. (Think 3 KB of one single .bat file menuing to do a few dozen tasks.) When choice is used liberally, along with variables, you can make it very simple to maintain, too. (We used it for updating various things, and the very first section was where all the variables were set, all you had to do when it came time to update was throw the updated file in the right place, and change a number in the batch file.)
Another non-functioning site was "uncertainty.microsoft.com."
The purpose of that site was not known.
I recommend bash or csh..
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?
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...
"...I think the Microsoft hatred is a disease." - Linus Torvalds
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.
Wow... just, wow.
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.....
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 every problem, there is at least one solution that is simple, neat, and wrong.
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.
Jumpstart the tartan drive.
Did some quick research on it and it does look like it would work. But I did find this information:
http://www.tek-tips.com/viewthread.cfm?qid=655463&page=6
Doctors destroy health, lawyers destroy justice, universities destroy knowledge, religion destroys spirituality
Wizard????
Did you see the freaking subject, much less the summary?
There are two types of people in the world: Those who crave closure
You could consider VB Script and HTML wrapped into a WSH file if you want a simple web GUI and being locked to IE isn't a problem.
I am becoming gerund, destroyer of verbs.
A wizard?
are you out of your fucking mind?
I am working on a project that would allow our customers to test our sending different PCL commands to LAN printers.
I will be looking forward to the first error is encountered by a user. You will hear someone in the cubical farm say, "PCL PC Load letter? What the fuck is PCL PC Load letter?!?"
HA! I just wasted some of your bandwidth with a frivolous sig!
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 !
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.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
Wizard? Pfft!
He needs to re-implement Clippy!
Think of how helpful this would be :)
...
I would also look to Powershell to solve his issue.
Before Powershell, I would have went with VB Script.
Because he was wanting a bit more of a GUI, HTA (HTML Application) would be a simple option. It is a local web page named .hta instead of .html and it runs with application security on the local computer. Any script you can put in a .vbs file, you can also put into a script block of a .hta. This is one of those little tricks that not to many people know about.
I use hta when I want to keep the flexibility of html/script as an alternative to a compiled vb.net app.
Im a gamer, not a grammer major. This post is full of spelling and grammer mistakes.
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.
If you don't know where you are going, you will wind up somewhere else.
Apple Script.
This ain't rocket surgery.
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.
Good people go to bed earlier.
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!
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).
Anything.
I cringe at the thought of using a Microsoft tool for this...
How well is DOS supported these days?
How well is Visual Basic?
Use a Microsoft tool, and you are one the second Microsoft dictates that a language or API must die.
These days all the open source languages support Windows quite well. In fact, Microsoft spends $$$ to help make that so.
I'd look at Expect or Python.
You would be shocked and appalled at the things I have done with the simple windows shell. Did you know that "FIND.EXE" is the only native commandline tool (that I could find) that can convert a UTF-8 stream into ASCII?
Just in case someone else doesn't mention it....
There is no 16 bit DOS subsystem in 64 bit Windows to run said BAT files. So your program will probably have a fairly short shelf life.
You can run CMD files which are almost the same as BAT files though.
Check into AutoIt (http://www.autoitscript.com/autoit3/index.shtml), we use it at work to do all kinda of stuff. You can do graphical interfaces, and you can even script graphical interfaces. You can have it run different commands with run(), or you can interface with the WinAPI directly.
If you do decide to work in it, make sure to get the full SciTE editor, the second download link. They include a stripped down version by default, but then install the full version, and it provides many more options.
I'm honestly surprised I haven't seen this yet on here. It's saved of lots of time (once the coding/debugging was done at least - I can now restore software activation after imaging machines!)
I can't believe no one has mentioned Windows Script Host. I believe it's installed by default on all versions of Windows since Windows 98. It's little bit difficult to explain, but you can write scripts in several different languages; here's a good place to start:
http://technet.microsoft.com/en-us/library/ee156607.aspx
I am surprised that nobody mentioned it.
Tcl/Tk is a scripting language specifically designed for automated testing and software quality assurance.
http://en.wikipedia.org/wiki/Tcl
Scripting in the 32-bit CMD environment is powerful enough to do all kinds of things well, and it works all the way back to Windows NT 4.0. You can add all kinds of functionality from later versions of Windows and the server OS's by simply throwing the supplementary executables into a folder on the Windows path.
Bottom line: If a batch file can do it, it's often the best way to do it.
Perl and Python are my favorite. If you want a single file solution, you could use Py2Exe or the Perl Development Kit (not free, but worth the $$$) from ActiveState to compile your script to a single exe, requiring nothing else. I have done this even with Perl scripts using Tk gui's. This allows you to stay in the easy scripting world, and still get the portability of a compiled c++ binary.
You can use bash on most Linux implementations
You're in luck: there is something better than being a trolling twat making useless suggestions. It's called "sticking your head in a vise."
What you do is get a vise, you put your head in it, and you twist the handle until it contacts both sides of your head. At this point you'll really have to turn the handle hard, but keep going.
You can stick your head in a vise in most wood shops.
Wouldn't it also be required to run on a windows box?
*DrugCheese rants*
...and even generate a small web page which, when launched from the batch file...
I don't think those two things belong in the same sentence. Hell, they barely belong in the same century...
Are DOS Batch files too 1990s to be taken seriously in 2010?
Hell, DOS Batch files were too 1980s to be taken seriously in 1998.
Call me crazy but I love DOS.
Hey, so do I. I love the TRS-80 too, that doesn't mean it's not completely obsolete.
"I don't care about the Constitution!" --Bill O'Reilly, November 17, 2009
I haven't used it for ages... but it worked very well..
http://www.jpsoft.com/
DOS batch files were tolerable in the 80's and 90's. Today, you have far more heterogeneous environments (like it or not, about 1 in 5 computers sold is a Mac today, and there's lots of Linux in academic and corporate back offices). Your DOS batch files won't run on them. For that matter, there are now versions of Microsoft Windows that they will no longer run on.
The world is moving to platform independent options. There's dozens of cross-platform scripting languages that you could use, for example. Most are included with most operating systems, you'd generally only need to supply the interpreter for one platform: Windows.
The EASIEST way, however, is Java. You can distribute the application by embedding it in a web page. Users will never need to know of batch files or worry which computer they are using (and which OS). It's easy for them, though tricky for you. However, this is just the sort of domain where Java's promise of write once run anywhere has a ring of truth to it.
Ummm... just about anything?
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
If you are in the windows world, almost everything is being back-ended (AD, Exchange, SCOM, etc...) by PowerShell.
Learn it now, or learn it later...
Steve
You are crazy.
These were going to be my points as well.. since I have mod points, modded your comment over making my own. .HTA files are great, very similar workflow to an AIR application (but IE as the engine, which is a mixed blessing)
Powershell is a nice alternative as well, you can do GUI via it, but it gets cumbersome.
Short of that, VS2010 Express isn't such a bad option.
If you cannot use Python, which is the best solution in my opinion, then use Javascript.
Python is open source and in some companies it could be hard to get approval to download and install it. In that case, use Windows Scripting Host to run Javascript code because it is all included. Do not use VB or VBscript because they simply do not have the flexibility and power to do the kinds of string manipulation that you will need for this.
Also, Javascript is a saleable skillset to have on your CV/Resume.
You can even put your Javascript code into a .BAT file so nobody will ever suspect what you are doing. http://jimlawless.wordpress.com/2009/08/07/embedding-javascript-in-a-batch-file/
It depends on your requirements - if you can install other shells such as powershell, perl, java, python .... then pick your poison. If you want to maintain your initial statement of a single file (and here my assumption is that it must run an all windows machines in your network) - DOS works. Why make it pretty ?
There is nothing wrong with a simple text menu in DOS - provided it is simple.
Yeah. VB, C++, Java, they all do PCL commands.
..but will it fit on a floppy ??
free, easy, capable.
Python is complete overkill and way too hard to learn and maintain for what the requester asked for. And, it changes versions every week.
I hate when people make that mistake. It's the Windows NT commandline. Whenever someone sees my bash prompt, they ask me if that's "like DOS", and I have to explain that no, not even close, that it's light-years beyond cmd.exe, which is light-years beyond DOS.
Don't thank God, thank a doctor!
Everyone knows that coreutil and man pages are all anyone needs. If grandma can't handle that, she needs to get off the Intervaxenbahn and go home!
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!
Coming from a windows background and trying to pick up powershell :) My motto whatever works, stick with it. Sometimes it's batch files, sometimes it's powershell or VBScript. I'm trying to force myself to write in Powershell, but the OO concepts are coming slowly. :)
So, I either have one monkey per plantation or a million monkey support structure?
Yikes, maybe I will try perl.
-- Sig under construction...
I'm using batch files to back up 120+ factory floor machines that run critical processes. The batch files read text files for input of which machines/partitions to back up and what org tree to store them in, makes full and incremental backups that auto-refresh depending on the percentage of data change, emails status/failure dumps and backup summaries, and archives the backups to off-line storage carts for a history. OK, so the backups, cartridge ejection and email functions are EXEs, but the mockup code written in '08 worked too well and is still running today.
Bonus fugly: a web page is used to update the text files.
Bitter twist: I'd load Perl in a heartbeat and port the batch files over if it weren't for bullhead company policies that say I can't load it.
What are you doing specifically with PCL? Could you get away with sending raw commands to your printer(s)?
.bat/.cmd files are supported in Windows, your solution could be not only the most efficient, but the most desired.
Sometimes providing a modern interface doesn't sacrifice customization. An earlier post suggests watching others use the tool to gauge how difficult it is. If you have the time to improve, deliver both and have the user compare. In the end it's the users that decide. As long as
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.
I know every time I try and run WinNuke on my 98 box I get some sort of crazy MFC file required.
On the Oregon Cost born and raised, On the beach is where I spent most of my days
I use Python at work for automated testing of embedded systems. It's easy to use and understand, and it works great! It's my scripting language of choice. Plus there is a lot of tutorials and useful info out there on the web. If you're lucky, there is an example script out there. I think you'll get the job done so much faster with Python. And if you need a simple GUI, the wxPython package gets the job done. That's what I recommend.
Windows batch files are dated. Most I use them for is calling python.exe and passing the script name I want to run. But you can also create an EXE for standalone distribution using pyinstaller if you need too.
Oh and if you do try Python, learn the logging module right away. It'll help a lot with debugging stuff and its pretty flexible.
1. For unit tests, you can't go past NUnit or CPPUnit and the like. 2. For scripted stuff, I highly recommend FitNesse. It's a wiki-based scripting language that allows "fixtures" to be written to tie into your code.
"Engineering is the art of making what you want from things you can get" - Jerry Avins
You get just about any scripting language you like -- javascript, jscript, vb script, even perl script. You get to control the chrome, and dodge security problems. You get a full HTML rendering engine of IE, you get all of the windows API including the file system, ODBC, microsoft office files, any peripherals you like, and all of activex. you get a networking system too. you also get the registry and powershell in any of those scripts. you don't need to generate a web page, you just are a web page. That includes anything IE can do -- flash, video, images, directx, and more.
oh and hta's can be run directly from the web if you like, so you don't need to distribute updates at all if you don't want to. they can access local and remote and online resources interchangeably.
Try PowerShell. It works well with dos batch files too, if for any reason you need to keep some stuff in batch files. The only gotcha I have found is keeping environment variables set from the batch file, but this is easy to remedy. We are very friendly in #powershell on irc.freenode.net and tend to answer questions pretty quickly unlike several other irc channels I frequent. We have user groups, meetings, and I have even heard stories about pizza.
A wizard?
are you out of your fucking mind?
How else are you going to get a robe and wizard hat?
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
What complexity does python add (for instance)? From the user's standpoint, if the .py file is associated with python (and it will be)
Is it associated with Python 2, with Python 3, or with "Windows does not know how to open files of this type. Do you want to look up the type in Microsoft's useless database?"
I haven't done this in a while. I know that Powershell can do a lot of things, but I believe that VBScript + HTA or Perl (Activestate Perl) are much more powerfull for what you want to do. Both would allow you to create simple GUI prompts for your users without having to write a lot of code. Powershell, as I understand it, is more for systems administration than for generic scripting.
If your users are okay with the DOS program, why change?
If, as I did for several of my DOS programs, you want to use this as a learning opportunity to teach yourself a more powerfull and flexible scripting platform, then go for it. In fact, if you have the time, I would suggest you write it in both VBScript and Perl so that you have a better understanding of both environments. You'll then be able to pick and choose the scripting environment, depending on what functionality you are looking for. I've always believed in picking the right tool for the right job and each has their strengths and weaknesses.
David
When he says "DOS batch files" he means the batch format that is still compatible with the 16 bit subsystem. Those don't become obsolete until everyone is running 64 bit and then, just change all your scripts to .cmd and magically they work again!
Seriously, you have no fucking clue what you're talking about. A windows batch file is just a collection of windows commands, so unless Windows 7 is suddenly obsolete, the commands he's scripting aren't obsolete either.
In fact, those old DOS commands aren't even deprecated yet, and only with Windows 7 is a suitable replacement for command.com being shipped with Windows. With 7 he can now expect to be able to run a powershell script on anybody's machine (so long as they run 7). That wasn't possible before, particularly if he didn't have the ability to install powershell before hand.
You're an idiot, you have no idea what "obsolete" means.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
Lol
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
ALWAYS USE THE WIZARD!
http://www.somethingawful.com/d/flash-tub/wizard-flash-cartoon.php
Karnal
posted by someone who traveled to 2010 directly from 1992.
I can't believe how many "serious" answers this post has received -- or how it was accepted to the front page of Slashdot!
http://winbinder.org/
A lot of people use LabVIEW for test applications because it makes talking to a bunch of different hardware really easy.
Most electronics companies where I've worked or consulted use LabVIEW for automated product testing.
You can download an eval copy from http://www.ni.com/labview/optin/trylabview
LabVIEW is graphical programming. I'm still loyal to C/C++, but all those text languages are so 20th century! ;) Until we achieve natural language programming, LabVIEW is as good as it gets for 21st century.
Putting humor aside, LabVIEW apps are very simple to write and deploy. The Application Builder allows you to create an EXE from your app and bundle it with the runtime in a nice Windows installer that you can send to your customers.
I've seen some suggestions on here for PowerShell. One limitation of DOS batch files is the inability to interact directly with .NET. Anyone on modern Windows should learn .NET since it is the preferred framework now for that OS. PowerShell can give you the .NET access, but LabVIEW will have a much quicker learning curve if you ever have the urge to delve into .NET.
The LabVIEW forums are very active, and the community gurus provide quick turnaround on support questions. For long-term maintenance of your test app, you're likely to find more engineers in the Test&Measurement arena that use LabVIEW versus DOS.
Good luck in your choices!
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've spent years of my working life writing and maintaining batch files, from synchronizing multi-threaded jobs to the polymorphic (you realize cmd.exe stores the next command as a byte offset into whatever is on disk when it goes to read at that offset?). It's true cmd.exe is ubiquitous and easy to modify at first, but "within the limitations of CMD" will come back to bite you.
Version one:
Version two ("hey, cmd has multi-line if statements!"):
Version three ("this looks simple to understand, let me modify it"):
Wham! Innocent admin can't figure out what the heck happened to the batch file, it doesn't work any more.
One day he may realize that his statement was turned into:
The innocent comment killed everything after it.
CMD sucks
You said it.
-Malloc
___________________ I want to be free()!
Since you're doing tests, your tests should have outputs, so use a makefile. This will allow you to test only things that have changed, since makefiles have built-in timestamp checking. For instance, let's say you have a series of ".test" files, and ".output" files, and a command "runtest" that runs your test, you can use a makefile like this:
/dev/printer
TARGETS = one.output two.output three.output
all: $(TARGETS)
cat *output >
%.output: %.test
runtest $<
Isn't this what VBScript is for? If you don't like VB you can use JScript.
Sorry my bullshit sensor overloaded.
Seriously? Really?
C'mon.
C'mooon.
Enough said.
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
A "friend" of mine used to always stick a copy of LoveDOS on anyone's computer in college that was left unattended. The ending comment of "Call me crazy but I love DOS" brought these "fond" memories back. It looks like someone has actually archived a copy of it, as well as putting together some screen shots and info about it: http://jeff.rainbow-100.com/?p=100 Ever since being inflicted with LoveDOS I have set up every computer I own to use a BIOS password.
If you system supports it, use REXX
I've done a lot of scripting for Windows in Python lately and I must say it's been a pure joy. There'a a TON of APIs and it's very easy to whip up something powerful quickly. You should be able to find an easy way to talk to the LAN printers (via sockets, etc.) and sending email from Python is also a breeze.
Does Ewmew Fudd have twouble with the lettew "aw"?
Ouch! Last thing needed when distributing printer test code is another wrapper layer that could interfere with printing.
Except maybe an additional patch to turn off the additional wrapper layer, assuming it actually does that completely, every time no matter what... maybe that is really the last thing needed.
If .bat files won't do it for you, then you could look into the Windows implementation of Perl, coupled with the Tcl/Tk module, which gives you basic GUI support so you can fancy it up with buttons and input boxes and such. After you've got the script working right, you can run it through Perl2Exe or one of the other available compilers and distribute your work as a .exe file. This has two obvious advantages:
A very important side effect is that you'd gain a little experience with Perl, which can work scripting wonders that .bat files could never do.
Sort of a caveat: I once made my living by writing simple perl scripts that pulled data from the text dumps of a legacy MUMPS database and returned .csv files that the QA guys could play with in Excel. So I'm biased. I've also left the Microsoft ecosystem for Linux, since I think the Microsoft ecosystem is terminally polluted on its own effluvium. So I'm really, really biased. (Perl is FOSS originating in the Unix/Linux world; Perl2Exe is shareware that I remember cost under $50)
Will
Simple, portable. I use it for everything.
...their interpreters. Powershell isn't as backwards compatible.
Languages compilable to self-contained executables not installing anything extra on your computer (not a single file) are typically a lot more effort to work with - and the users can't just read the file to find out it's trustworthy to run.
Only exception to above rules I saw in comments here (pardon me for not linking, htc hero is really hard for this stuff) is the PAR perl exe packager. I'd jump to try that out if I developed for Windows.
I'd say keep it simple and avoid the colors. They bring extra complications and add no business value.
I admire your mad batch skills. How do you talk to the printers and send mail without extra dependencies, by having the script write out small com files to run, eh?
I was the real korpiq until I woke up clowned.
Does this get around the DOS limitations without losing the DOS-vibe?
http://www.4dos.info/v4dos.htm
LabVIEW. Can't go past it for test and measurement. Expensive yes, but amazingly simple!
There are a lot of good suggestions out there by people that apparently didn't read your full post. Since you are using batch files currently, it's assumed you are using windows ;). If your windows systems have IE 5.5 or higher, a good single file solution would be to use a .hta file. There are quite a few examples out there, and you can have your logic and HTML UI in one file. HTA is the only type of solution that I am aware of outside of batch files that would allow you to only have to deliver a single file to run on most windows systems and not have to install a script interpreter or runtime. For anyone who has written a VB app, you probably know that VB runtime compatibility across diverse systems can be a pain to manage.
If you have powershell runtime available on the systems already, that would probably be the best solution, and the most "future proof" for windows specific implementation.
There is a product named TestShell written by a company named QualiSystems. it's a visual studio for developing tests without the need of knowledge of a programing language. it's very robust. check it out at: www.qualisystems.com
I used take command ago for DOS scrips (years ago), and I still use it instead of normal command prompt or power shell. The commercial version seems to support active scripting, but I've personally never tried it. At the moment I'm using the free version of TC as replacement for the normal command prompt / powershell.
http://www.jpsoft.com/
IronPython would be my first choice. It's excellent.
Have you overlooked that apart from Command.COM there is also CMD.EXE? All you have to do is rename your file from .BAT to .CMD and you move up to the area of 32bit computing. And yes CMD's are faster for it.
Of course, the only downside of this is you would need to learn perl.
One of the few programming languages that requires you have a Ph.D. to write a 'hello world' script.
The primary reason I did this was readability.
Yeah "readability" is *always* the first thing that comes to mind with Perl.
I can look at them a year later and know exactly what I did and how I did it.
I don't doubt it. Unfortunately though your COWorkers are still trying to decode your work....
All I had to do was be a little disciplined about script formatting and variable names (it's really not that hard).
Indeed as this well disciplined Perl example by Mark Dominus clearly demonstrates:
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&}%p;$_=$d[$q];sleep rand(2)if/\S/;print
Perl - always the language of choice for readability! :)
Swap user numbers with me:
how to invest, a novice's guide
Use VBS... it was designed to replace batch files and it can do all of the same stuff. Even more, I recon.
After all, 100 million script kiddies can't be wrong. Just make sure the user has the ability to tell the printer to STOP printing test pages and that the vbs doesn't automatically copy itself to all other attached computers on the network...
This message brought to you by Jack Schitt's Previously Shat Shit
Perl.
Just about any UNIX shell, including 'sh' and most of its modern derivatives, is orders of magnitude more powerful than DOS batch file processor.
PowerShell?
I used to use PB for install scripts back in the mid-90s - a sort of extension of DOS batch language that produced executable code. A bit like VB for DOS, come to think of it - you might have a look at that as well: Powerbatch: ftp://garbo.uwasa.fi/pc/batchutil/pwrbt14j.zip VB for DOS: http://www.qbcafe.net/cgi-bin/downloads/download.pl?dlid=capuqWZASbvLM&compiler/qb_compiler=vbdos.zip
Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it.
If maintaining the set of DOS batch files doesn't create you nightmares, go for it!
Might not be a problem at the start, but as they grow in number and complexity... the probability of nightmare approaches 1.
Besides, if something goes wrong while testing, without the ability to debug/trace the execution, how can you make sure it is the product that's going the wrong way or, instead, your scripts have bugs somewhere?
Questions raise, answers kill. Raise questions to stay alive.
Dear Crazy,
In your hands, perhaps DOS is the best tool for the job. :-)
Use VBScript, not that complicated to pick up by looking at examples and RTM'ing the help file. Then use a HTA to present the interface, and even take feedback inside the HT
http://technet.microsoft.com/en-us/scriptcenter/dd742317.aspx
http://www.microsoft.com/downloads/details.aspx?familyid=01592c48-207d-4be1-8a76-1c4099d7bbb9&displaylang=en
Assuming that you're trying this out on OSes newer than Win2k, powershell may make a nice alternative. You can use the same structures that you're familiar with in command and the ability to add more complex components when/if needed.
--- no sig to see here... move along.
Forget about batch files, unless all they do is launch better tools and nothing else.
There are many alternatives. You could go with Python, Perl, Powershell or, if you want it really really simple, small and powerful, use Lua. Package it with the app and people won't even notice it's there.
Plus, you can start it up with an one-line batch file, if you want that nostalgic feeling.
From reading the comment, I see everyone suggesting their favorite scripting language, but I think it misses the point.
If your script works as you like, then keep it that way, and as others mentionned, just develop a satelite app that handles the parameters of your script and actually launches it. This way everyone is happy, the sysadmin that wants to automate his tests can directly launch your script from his automated tasks, and the user that wants to do a quick test can use the GUI.
I do agree that providing a UI in DOS can feel quite elderly and doesn't look very professionnal. I mean, use VisualStudio Express (C# or VB) and write your small GUI, you'll see, its pretty simple to use. Then bundle your app with the script, and everything will be fine.
You can also decide to build the UI from a config XML file that could allow you to easily add new options to your UI for additionnal command line options ( something like ), this could make your app pretty scalable if anybody modifies it, but I think i'm out of the subject, and you probably don't need this ... :o) .
Good luck with your project !
One of the few programming languages that requires you have a Ph.D. to write a 'hello world' script.
WTF could be easier? And with a UID that low, I have to wonder if you bought it off Ebay after you said that.
Tequila: It's not just for breakfast anymore!
Where I work, we have used Python to create a regression and qualification testing framework for embedded avionics software. It has worked out exceptionally well. The testing framework was originally developed on Windows, but we are also porting it to Linux. (The Python parts are completely portable, of course... but because of the nature of the application we also had to create libraries in C to drive some specialized hardware, and the C modules do require some porting effort.)
I don't know about anyone else, but i have been using Kixtart (http://www.scriptlogic.com/kixtart/) since the days of Win95 for all my windows scripting needs. It is simple, powerful, intuitive and there are a ton of UDF's that are already out there to do just about anything you could imagine. This allows even a non-scripter to build an application in minutes, package it in a Win32 wrapper and distribute an executable. Piece of cake. Even though development stopped on this a few years back, it is still a very viable alternative
I would say that anything is better, at least in terms of expressiveness; even JCL has richer syntax.
I can understand why you like DOS, in a way - back in the day, I used to know the BIOS and the DOS interrupts by heart. Still, now I use ksh - I wouldn't be surprised if you can get that (or bash, which is a tolerable alternative) for DOS. There is a lot more to learn, but then, of course, it lets you do much more too.
Oh, and upgrade from DOS - Linux is what DOS aspired to, originally, as evidenced by the old XENIX system.
You're focusing on the wrong thing. You don't want simple, you want maintainable. Maintainability is the biggest requirement in automated testing. Simplicity can be a very helpful factor in maintainability, but using a restricted language is a negative factor against maintainability.
I don't know what other programming language would allow this and be as simple.
Any programming language. Perl, python, ruby, and powershell are all simple to build and execute and would work well. But it's not like setting up any language to do what you want is that complex.
Rule #1 of automated testing: Automated testing is software development, just with different challenges.
Corollary #1: Everything that is helpful for software development is helpful for automated testing.
Write me an industrial accounting system that is time efficient for data entry and uses some self-documenting interface like a wizard and I'll be impressed.
When you want your data entered quickly and your data-entry people want to be efficient, you want efficient user interfaces that don't coddle people who've been doing their job for years. You create interfaces that make sense, document them to death and do training.
Hire an army grunt who memorized "In situation x, hit green triangle twice" over someone who requires a wizard to enter their data any day. One is teachable, the other is not.
- Michael T. Babcock (Yes, I blog)
Having migrated to powershell for all logon scripts in my domain I would suggest thinking about it. A lot of the dos batch functions can easily be ported with minimal fuss. Having not done any object oriented programming, it was a bit of a bear to wrap my head around the changes. Two tips that would have saved me a lot of time: 1. Calls to win32 gui apps run in the background and your script continues with out waiting unless you include a Diagnostic Process wrapper and specify the .waitforexit() method.
2. system.windows.forms are good for gathering user input from people who freak out when they see a "Dos box" (side note, the first focusable element that you add is selected when the form is generated. Most of the PS examples I have seen online do not point this out and have the focus set on something other than the first user input item).
"I myself am made entirely of flaws, stitched together with good intentions."
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)
Why reboot onto a CD ?!?
Python, Perl, and the likes are all freely available on Windows too.
Several even features way to pack everything needed (Run-time env + your script + its dependencies) into a single installer or executable.
I would definitely vote for them as they are widely available language on lots of different platform and each feature huge collection of extensions.
(As are Visual Studio Express and Monad PowerShell if you deffinitely need a pure Microsoft solution while trading some freedom and portability)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Seriously, you have no fucking clue what you're talking about. A windows batch file is just a collection of windows commands...
Yeah, but we were talking about DOS batch files. Feel free to lecture me all day about what he means when he says "DOS batch files", but I'm going to continue to interpret "DOS batch files" to mean "DOS batch files". Ok?
...only with Windows 7 is a suitable replacement for command.com being shipped with Windows.
Um...try cmd.exe? Only been around for, what, 10 years now? You only use command.com for compatibility if you specifically need to run DOS programs from your batch file, which I doubt is the case because if it were, the OP would have said "I need to run DOS programs, help!" instead of "I need to send some messages to printers, is DOS the right approach?"
You're an idiot, you have no idea what "obsolete" means.
I may be an idiot, but you're clearly the one who doesn't know what obsolete means, or deprecated for that matter. From wikipedia: "Obsolescence is the state of being which occurs when an object, service or practice is no longer wanted even though it may still be in good working order. Obsolescence frequently occurs because a replacement has become available that is superior in one or more aspects." Since win32 is superior in one or more apsects to DOS, and nobody but OP really uses DOS, I'd say that constitutes obsolescence. The fact that the commands still work in the DOS subsystem has nothing to do with whether they're obsolete. As far as the things you say "aren't deprecated yet", deprecated doesn't mean the commands have been taken out, it means they're only still available for compatibility. Here's a hint: if you have to say "yet" to claim that something's "not deprecated", that means it's already deprecated. Here's another hint: try looking up big words before lecturing others on what said words mean.
"I don't care about the Constitution!" --Bill O'Reilly, November 17, 2009
RunRev.Com
You can get revMedia for free.
revStudio and revEnterprise for 30 days.
It uses an xTalk derived language. Very easy to use but very powerful. I use it for everything from Database migrations, to full fledged web-ready client apps.
Very powerful, very simple.
If you like old DOS commands, probably you'll like Take Command Console from jpsoft. It's a basic and free command processsor derived from 4NT and 4DOS command processor. It comes with with 111 commands, 140 functions and 97 internal variables that allows you to do several tasks with basic batch commands, including IF-Then-Else, DO Loops, Switch, subroutines and enhanced options for shell commands like copy, move, delete. It also supports ANSI color commands.
That's great for playing a DVD, but absolutely sucks for a complicated task. I see people spending hours clicking around menu-driven software (eg., SPSS, EPrime, Excel) trying to get something to work because they have been trained to never look at documentation (and be afraid of anything that requires typing). /rant
"Knowledge is the only instrument of production that is not subject to diminishing returns" -Journal of Political Econom
AutoHotKey is the solution for your problems (http://www.autohotkey.com). You can program all sorts of different applications, compile them into .EXE files, create GUI's (if you want), etc. The programming language is very very intuitive, and it works great. I work for one of the largest IT firms in the world, and we are accomplishing some major things as far as automation is concerned, all using AutoHotKey. It is definetely not your typical macro programming language, it is way, way, way too powreful to be considered that at all. It's basically a full-blown language, and it is incredibly easy and intuitive to use. Try it out I gaurantee you will fall in love with it.
Nearest equivalent for X / Linux that I've used is xte, which uses the XTest extension to send keyboard and mouse events to the desktop.
xte is usually included with the "xautomation" package for various distributions.
I've also seen people use xvkbd -text to automate keystrokes (often in concert with xbindkeys), but I've found xte works a bit better in many cases, for example, when activating CTRL/ALT/Shift/etc. modifiers.
To complete the package, xprop can also give you some useful window state information and control so you can find and manipulate application windows.
print "Hello world!\n"
I don't see how that requires much in the way of higher level education to master.
Perl is a highly permissive language: it assumes that the programmer knows what he is doing and tries to keep out of his way. It is a lot like contemporary Internet English: in both cases most users are not fluent in the language, let alone capable of writing truly elegant stuff. But in both cases the users are generally proficient enough after a reasonably short period of study to get the language to do what they need. Just as there is a lot of really crappy English language on the Internet, so too are there a lot of really crappy perl scripts out there. But a Brazilian does not have to be able to write perfect English to ask a newsgroup for help with a problem in 3D modeling of turbulent flows. Similarly, a sys admin does not need high level programming skills to write a perl script that would read a dump of the day's network logs and extract all entries from a specific machine.
Will
Dude, at work I used to have an application with five commands:
login [user/pass@server:port]
logout
verbose [on|off]
output [file]
call [file]
Still I had to train a guy to use it, not an old geezer but younger than me in his 20s. Everything needs a manual...
Live today, because you never know what tomorrow brings
That's the worst idea I think I have seen in this thread! Lets take something simple like a batch file, and search for a way to make it better. Still simple, but better. Oh wait! I can make a wizard! There is absolutely no complexity involved in that right?!
Genius.
Yup, because when I said, "disciplined about script formatting and variable names," what I was referring to was the practice of keeping all variables anonymous, not indenting anything, not using proper line breaks, not commenting my code, and loading functions with anonymous inputs that are anonymous outputs from preceding functions.
/endsarcasm
Yup, all those practices are, most certainly, what I mean when I say disciplined formatting and variable naming practices. You hit the nail on the head AC!
(And please don't woosh me, yes I know it was a joke).
Motorcycles, Robots, Space Gossip and More!
You're crazy!
Years ago I hacked together a small "boot strap" utility in assembler and compiled it with NASM. It was a self-modifying program that, in its original form, didn't use any non-printable (non-echoable-to-file) characters. Once in memory, it modified itself to provide what printable op-codes couldn't.
What it did was allow me to echo hex coded strings to files, so a batch file could create the .COM, then use the .COM to create any other file, including binary .EXE files.
By the time I was finished, I made a "bin2bat.exe" program that created self-extracting batch files.
I can now do ANYTHING with a batch file that can be done in ANY programming or scripting language (assuming DOS is available). (Hoping to win a case of beer on a bet, I once made a 65 MB batch file that, given a ready DOS prompt and an available hard drive, would install Windows 95. I never got the beer, but it was still fun!)
When I made the switch to Linux, I still tinkered with script files that would run as both BASH and BAT scripts.
These are some suggestions based on the assumption that you are strickly a Windows shop. In order of technology (more "primitive" to more "modern")
1. Stick with the cmd script, it will run on just about anything though it can be hard to make a batch script which is not brittle and some common tasks are hard to do (lack of coreutils-like tools on Windows)
2. Use one of the WSH (windows scripting host) languages eg. vbs, js, etc...
- it is more flexible than batch files (for example try getting the date or time in a batch file, it can be done but simple things are a pain in the arse) .Net which is for all intents and purposes a completely different language than VB "classic")
- it is natively supported on Windows 98 and later. I venture a guess that nobody in your shop is running anything older than XP but my point is that you don't need to install ANYTHING: no interpreter, no runtime library, etc...
- VB Script is fairly intuitive if you have ever done VB6 or earlier (not VB
3. If you are all using the latest systems like Server 2008 and Windows 7, you can use Powershell 1.0 without additional installation (maybe vista has this already but I'm not 100% sure)
Alternatively, if you have a mix of Windows, Linux, Solaris, HPUX, AIX, yadda maybe you want to consider using something like Cygwin on the Windows hosts and having common bash shell scripts across all systems. However, I suspect that even if your environment is heterogeneous, you have more Windows machines than UNIX-like systems. So this would be favoring the uncommon case rather than the common case, I guess. Plus, no offense to skilled Windows users, considering the market share and demographics I would assume that the UNIX users would be more well-equipped to run custom scripts for their platforms, while the majority of Windows users would be hindered by a less-than-streamlined experience.
When I saw this article, I thought my RSS reader was broken and it was returning feeds from really old articles. I figured I'd click on it and see some clever use of Windows batch files... but no. I read the summary and thought "LOL: it really is returning old articles!" Then I saw the comments... and the date... holy moly.
I wrote a batch file last week. It copied some files from point A to point B. When it had to conditionally copy one, I wrote a C# app because I didn't have time to learn powershell. But writing a batch file to deal with a printer? Does that work with LAN printers? Did you have to map an LPT port? Dear Lord! Get your skills up to date before you find yourself sitting on your front porch with a shotgun, trying to get kids off your lawn!
(Mods - yes, this post was meant to be funny)
Powershell 2.0 FTW!
Funny I got called troll... obvious, ok, but troll? The guy posts a questin about DOS in, let me see, 2010... and I'm the troll?
Heh, whatever.
To the guy who suggested that I put my head in a vise... (and the genius that said "LOL"), I answer: you are part of the reason I fell honored to get "-1" here.
This was once a place for great guys. Seeing you I sincerely feel it's great to get -1... I even hope for another negative rating, maybe a -2 if that exists.
Besides, just between us, I'm a foreigner and don't really know what a vise is... I probably will search on google after this... is it some kind of vase?
I hope some /. founder read this and ponder whether this is what they planned the site to be...
I'm surprised that IronRuby - a .net based Ruby implementation - hasn't been discussed in this context. The recent 1.0 release provides excellent integration with .net, and there is a host of good unit test frameworks for Ruby that works well with the IronRuby. For Windows GUI tests, Project White provides a very user friendly layer on top of Microsofts UIAutomation framework. For web integration testing you can use Watir or Webrat.
The language is fairly easy to learn and IMHO much easier to work with than VB.
For the Python buffs out there, there is IronPython which has the same capabilities regarding .net integration.
I don't know how old your machines are but I believe every version since at least Windows 2000, maybe even 95, has had Windows Scripting Host so no need to have your users install anything.
You can use visual basic scripting or javascript (jscript)
http://en.wikipedia.org/wiki/Windows_Script_Host
There are books on it.
If your stuff works as DOS commands great. If you find you need more power to your language and you don't want users to have to install anything than Windows Scripting Host is probably your only other option.
My understanding is that Perl2Exe is just a wrapper for the interpreted code. If there is an error, the error message will contain all of your code.
Is the rc shell by Tom Duff, incredibly simple, elegant and powerful. And you don't need anymore to use obscure operating systems to enjoy its bliss.
I have used it to build a whole content management system, and has turned out to be as close to perfect as any piece of software could be.
"When in doubt, use brute force." Ken Thompson
Benefits of python:-
1. You can write the core of the application to be accessible as a command line utility.
2. You can optionally add/extend a GUI based on QT, TK or the Wx toolkit.
3. You can compile it if required to remove the dependencies on the target deployment platform.
4. You can integrate unit tests using the unittest module.
5. You can easily output HTML using a variety of ready made frameworks or templating languages.
6. There is loads of code out there to learn from.
7. Arguably easier to read & maintain than DOS batch files.
8. Not dependent on any single vendor.
9. Free.
Just my 2c.
I prefer documentation over some stupid, poorly designed wizard that doesn't allow me to do the complex things I need. Stop designing everything for the lowest common denominator. Youtube already exists. Someone will always be too stupid, or find a way to be stupid and there's nothing you can do to fix that.
In my company, I had to do also an automated test suite.
I began with batch files, because there were already some very basic scripts done by another developer and I as extending them.
But, the suite needed some more advanced things, like time profiling. Batch files were too bad to do time calculations, even the simplest.
So, I decided to migrate to a scripting language, and I was between Tcl (I already did things with it, even controlling Networking printers through SNMP and PCL) and Python (Never touched it).
Even I like more the Tcl syntax, I decided for Python, because:
- Python has a more active community and is not dying, unlike Tcl
- I could learn Python
- I could get help from some colleagues at my job
- If the thing needs to be maintained, it will is more likely to get people that knows Python than Tcl
- It has some modern developments that Tcl does not have
But, I also had some problems. First Python is now in a phase of deep restructuring, and I was doing it in Python 3 and had lots of problems, mainly because of some extras for Python that are not compatible. After, I discovered a chat Channel whose topic says "It's to early to use Python 3".
So I downgraded it and got the job done. So, if you go for Python, I recommend seriously 2.6
And you can also have some Windows things, may be it is why you are reticent of moving out from batches. I used winreg module to access the Windows registry.