Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Suppose there were several projects mostly maintained by smart interns, who eventually leave after a period of time. Scripts are used here and there in key parts, for example, to back up a database, rename it, zip it, move it over ssh, unzip it, and then to restore it with different settings. You know, the scripting stuff.
The programming languages for the application side is set, but those for scripts have been relaxed. Currently there are probably healthy mix of bash and .bat file, and maybe some Perl.
1) To avoid language proliferation, and 2) because I don't want to force bash upon future Windows programmers, I'd like to set an "official" scripting language.
Google picked Python for this, and it's famous for being readable, easy to learn, and having good library; however, I personally don't find it that readable compared to C-like grammar, Pascal, or Ruby.
In any case, if you were to be forced to use only one scripting language on a Windows machine (with Cygwin if you want to) for all scripting, what would you like it to be, and why?
Related religious wars:
What Is The Best Scripting Language To Learn?
Which Scripting language is best?
PowerShell - designed from the ground up to be a Windows scripting language, and it can hook into the CLR for advanced functionality.
(yes, I realize this doesn't run under cygwin... but why is that a requirement?)
When I've written cross-platform product installers, coding a UNIX shell script for Linux/Mac/Solaris etc. is really easy, but trying to do equivalent tasks in BAT is like working in the dark, underwater, with both hands tied behind your back. I can't state strongly enough that BAT scripts are a blight on humanity.
So what I've heard about PowerShell makes me happy. It's a life-saver for Windows developers. The only trouble is that I believe it's still a separate install, it isn't available by default (I've read that it'll be on Windows Server 2008 and Windows 7).
Oh well, it only took Microsoft 20 years to replace BAT scripts with something as capable as UNIX shell, so I guess I shouldn't be too ungrateful! >:-P
Get the installer for PowerShell here:
http://www.microsoft.com/windowsserver2003/technologies/management/powershell/download.mspx
I'll try to provide an alternative - JavaScript and VBScript work fine too even on Windows versions long gone, and they don't need a seperate installation like PowerShell. ;) Of course, PowerShell has more power :P
I'd urge you to give Python a chance. It looks a little odd to 'C' programmers at first, but its easy to pick up and more importantly easy to remember. You are going to have interns of various skill levels using and modifying the code so you want something that can draw from a wide user base. And if you are going to go to the trouble of installing something new why choose powershell which is going to be a dead end for anyone using it.
Powershell. It's got the breadth and the depth, and is fully supported (now and in the future.) Unlike Cygwin, for instance.
The best scripting language I have come across for interface and control type applications in Windows is AutoHotKey. Anyone developing on windows should learn about this language... It can save you an enormous amount of time just automating retarded windows tasks...
One of the most useful tools I have come across for Windows is Texter
This utility is written in AutoHotKey and saves me from having to type anything more than a few times... An indispensable tool for a coder or anyone filling in forms or tickets...!
If you are like me and want to display nifty progress bars or splash screens while your script is doing it's magic (instead of a black/gray command prompt window), use AutoHotkey. Showing a progress bar is a PITA with JScript/VBScript (WSH) and/or PowerShell from what I've found. In AHK it's as simple as:
Progress, b2 m, ACME App, Doing some magic...
Also you can interact with almost any control in any window and automate apps which are not meant to be automated.
For your particular description, PowerShell sounds like a good way to go ... but I would make a strong case for JScript under WSH (or JavaScript under Rhino/etc.). Sounds like you like CYGWIN, but Powershell does not currently have support for other platforms (too much native stuff I think -- that's a separate discussion IMO, but Google should answer it).
I pretty much make the case here:
http://mikesharp.wordpress.com/2011/04/03/jquery-for-administrators/
Some highlights:
JavaScript is installed by default on every Windows OS after '95
JScript scripts work "out of the box" with Active Directory
ECMAScript is an open standard (which JScript is an implementation of)
Through ActiveX/COM JScript can do most of what Powershell can do and under Rhino it has the power of Java
Can be used to create HTA applications (and later, metro apps with WinRT/HTML5)
JScript doesn't have direct access to the .NET framework -- although there are a few 3rd party JavaScript engines in pure .NET that interpret it and can share objects with it like Jurassic and IronJS. Also wrappers like JavaScriptDotNet (around Chrome/V8).
Powershell will likely be faster than JScript under WSH, but the same might not be said of other 3rd party interpreters.
Just please don't go with VBScript (lacking try/catch, no real OOP, proprietary, deprecated, etc.).
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have been contemplating moving forward from using the cmd.exe command line program which provides a command line interface and a batch programming environment that extends the one
available using the old command.com program on the old DOS operating system. The cmd.exe
program has been available on Windows system for a very long time. However, I feel that
it has its limitations in terms of usability and flexibility.
I have heard that PowerShell can be used to manage various Microsoft products, and also
supports snap-in modules for third-party vendors, supports several very useful programming
constructs such as pipelines, and above all is tightly integrated with the .NET framework,
which of course makes the PowerShell programming language very powerful.
Perhaps this question is somewhat broad, but in view of the existence of several alternative
programming environments such as Python and Perl which are used for system administration
(these in many ways have slowly replaced shell scripts on Unix systems for more complex
tasks quite some time ago), I was wondering where PowerShell fits into the ecosystem,
and above all whether it is worth learning, and especially if it is worth learning
when someone already knows a tool such as Python or Perl which is also used for
system administration. Is PowerShell more of a system administration tool, or
is it a more general programming tool that does not require compilation,
unlike, say, C#?
What I can see as advantages is that it comes preinstalled, and that you can invoke
.NET API functions from within it.
If anyone can sort out a few scenarios demanding that it be learned, especially in the
case where other programming tools are already known, I would appreciate it. In particular
I would like to know, besides quick .NET scripting, what sort of tasks are generally speaking
more suitable to PowerShell programming.
Thanks.
The number one reason to use Powershell is that Microsoft is starting to push all it's product management tools to PowerShell. In fact, when working with things like Exchange, there are some things you can only accomplish with powershell anymore.
The second reason is that powershell is a full scripting language, dos batch command language is not.
The third reason, is that anything that is possible in .Net is possible in PowerShell (sometimes with a bit more work, sometimes with a bit less).
Also, there are some companies, like VMware that the only command line based interface released for their products is via a powershell snap in or module.
And, in my humble opinion, it is a pretty fun environment to work in.
Piping objects is an extremely powerful feature.
Going from DOS to Powershell is like suddenly acquiring opposable thumbs. It's bigger, more complicated, and for some few very simple tasks it's more cumbersome, and it doesn't take very long to wonder how you ever did without it.
Mac has applescript 'built in' and I've found its pretty nice to work with for automating stuff.
What's the best windows equivalent?
Maybe PowerShell -- but it's really much more powerful than applescript. VBA only exists within specific applications that supply it, such as Excel, not stand-alone.
VBScript and JScript are standard Windows Script Host languages. See Microsoft Windows Script Technologies.
I discovered python when I moved to a PC and was looking for something to do all the kind of stuff I'd usually do with applescript. As someone who learned most of my programming skills using applescript it came pretty easily to me. Best thing is that you can use it on any platform.
BTW applescript has been around a lot longer than OSX.
Powershell is the program to learn if you want to automate stuff in windows. Microsoft is deprecating vbscript, which is part of Windows Script Host, and pushing Powershell as the modern replacement for vbscript. For example, Microsoft is creating more and more APIs for Powershell. On the other hand, vbscript bears a great similarity to vba, which is the default program for automating Word, Excel and Outlook.
Just for completeness, there is also the rather dated AutoHotkey. Originally designed to provide system-wide hotkeys to automate things, it can also be used as a general automation tool.
However, I cannot recommend it. The syntax is horrible and obscure, and that's the reason they are currently doing a complete haulover for version 2.
This is related somewhat to this question about a better shell terminal/gui-interface for cmd.exe
In my quest to find a better shell terminal, the only useful thing I came across was Console2, other alternatives weren't free and generally didn't offer much more than Console2 to make them worth their price.
I can't help but wonder, "how come"? The shell terminal is a very valuable tool to a programmer, yet no one came around to try and do a better job than cmd.exe (except for the guys # console2)??
Surely designing a command line shell terminal emulator can't be such a hard task!
Has anyone tried writing a shell terminal emulator before? What's in it? Any resources out there (say, if I want to program my own shell)?
UPDATE
17/07/2009
I rephrased the question, what I was referring to as a "shell" is actually called a terminal emulator (at least in the linux world). I only realized this recently so I thought I should revisit this question and fix it.
There are plenty of shells around for Windows, bash under Cygwin is the one I use the most, and it's certainly free. I have to be honest here, cmd.exe has come a long way since the batch file processor of MSDOS. It's actually quite powerful, but still not a pimple on the rear end of bash :-).
You should try to write a command line shell, it will be an education for you. It's not that hard to do the basics if all you want is a program launcher.
But, if you want all the power of a real shell, including a full blown programming language, job control, piping, output redirection and (seriously) too many other things to list, we probably won't be hearing from you for a while. Except when you pop up your head to ask us esoteric questions about how shells should do this or that.
What about PowerShell from Microsoft? AFAIK it's free, and gives you C# power right in the shell, and tons of other features. But, it DOES require the NET Framework...
I won't endorse it yet, as I haven't really used it, but it's on my list to do...
My bets are on Powershell for the future if you are a Windows guy.
PowerShell will be installed by default on Windows Server 08 R2 (WS08R2) and Windows 7 according to MS.
I have used Powershell myself and found it to be very useful, and if you are familiar with .NET then its all the more easier.
Download a two page reference document here, this is all you will need to get started.
I mean the gui-interface part that displays the text,
Ah! you mean what we call a "pseudo-tty" or a "terminal emulator" in unix. In windows, I guess it is called a "console host". I do not use windows, but I heard that console2 is very good.
Seems there are others:
http://www.powershellanalyzer.com/
http://powershellide.com/
http://www.codeplex.com/PoshConsole
and, of course, for real programmers, you have the shell mode of (x)emacs :-)
Erm... what about all the ports of Unix command shells to Windows?
Just go with cygwin and log on using PuTTY. So much better than the standard console. :)
Also, Python (or perl for that matter) can replace the shell entirely.
You might want to try Take Command Console, formerly 4NT, formerly 4DOS.
Quick summary of points you might care about:
Command line editing with filename completion, history, and cut & paste
Integrate PERL, Ruby, REXX, Python, and any Active Scripting language
Fast - 20-200% faster output display than the standard Windows console
Integrated file explorer - examine directories, drag and drop files
Upwardly compatible with CMD.EXE with literally thousands of additions
Not free (except trial version) and not open source. I haven't tried it myself, but I was a 4DOS junkie back in the day, before Cygwin.
If you need handy terminal - give a try to ConEmu (I'm the author). It is a Windows console window enhancement (local terminal emulator), which presents multiple consoles and simple GUI applications as one customizable tabbed GUI window with dozens of features.
Another answer and comments
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm not the best programmer so I found it was much easier to write a program as several separate executables, which occasionally call each other. But now I need an easy way to actually run them without writing detailed instructions like Run file one, wait until its completed and no longer in process manager before running file two, file three can be executed 15 seconds after file two has been created. Then Add a key to your registry. Etc. I figure there must be a good software out there where I can just drop all my exes in, tell it when to run them, and output one file for my clients to run. Any ideas?
Inno Setup is easy to use, free, open source and scriptable if you need it.
I've always had a good experience with NSIS
It's open source
It has a big community (and hence lots of plugins)
For simple things, its script-based approach is nice and easy
It's lightweight and fast
On the downside, if you want to do something more sophisticated, you need to use something that looks a bit like assembly language - very odd, and not particularly pleasant. Thanks for the comments about that - I'd forgotten all about it!
Inno Setup is simple, light-weight and covers a lot of ground. I've used it for 5-6 apps over the last 5 years and it never let me down. Highly recommended!
Before that I used InstallShield, which is one of these systems that are so complicated that they "offer" you to "utilize" their "professional services" to create your installations. In other words it's kind of a hack that only managed to build a customer base in the childhood of Windows because there was no competition. It's a bit like a 747 that runs like a Trabant.
The worst, by far, installer product I've worked with is "WISE for Windows Installer". This had me literally smash my mouse in the office floor in frustration. It is (or at least was, 4 years ago) utter crap and should be avoided at all costs. This is exactly the kind of software that those pesky license agreements are there for, else the publisher would be sued into oblivion...
Yes, two ideas:
If you're looking for a way to statically put files, registry keys, start menu shortcuts, et cetera on your customer's systems, you should be looking for an installer solution. Many of these exist, and choosing the best one mostly comes down to features and pricing. I happen to like Caphyon's Advanced Installer, and it does have a freeware version that looks like it might meet your needs, except for the ability to run executables at scheduled times (which would require the Windows Task Scheduler support only found in the Enterprise edition, which is in the ultra-expensive price range, comparable to InstallShield...)
If controlling the flow of events on your customer's systems is more important than getting the executables on the system, you may want to look into Automise, which is basically an ultra-friendly UI for creating scripts, which makes things like scheduling tasks quite easy.
Anyway, you can download trial editions of both pieces of software, to see which one (or possibly both) will allow you to do what you want in the easiest way, or at least give you some ideas on how to best serve your customers. It may turn out that simply adding a new, 'supervisor' executable to take care of registry keys, scheduling, etc. could solve the problem without any third-party add-ons...
WixEdit is an open source (install shield like) authoring tool that uses the Wix Runtime from Microsoft.
Wix Tutorials
If you don't have any specific requirements apart from being able to install a few executables, then basically anyone will do. I'd recommend NSIS, not because it is particularly easy to work with (it has a cumbersome assembly-like language which isn't to practical to do more complex things in), but because it is free, has a large and active community, and it generates fast installers with very low overhead. As an extra bonus, you can run the compiler (i.e. the tool which generates the installer) on Linux.
Edit: ...and whatever you do, do NOT use InstallShield.
The ones I've worked with are:
InstallShield
NSIS
INNO Setup
Custom created installer
My preference is INNO Setup. It's free, it's easy.
I heart wix, MSFT's open source, declarative (XML) based toolkit for building MSIs.
It's ace.
If you want to install binaries, add reg keys and even run "custom actions" (have your own code execure during install) you should have a look at it. Then you'll have a one-click (msi) solution. Good eh?
Definately Wix. :)
Wix allows you to do the most things with ease and the difficult things without hacks, it's free and open-source.
You can use Wix within Visual Studio (using Votive) or you can use it using the .Net SDK, MSBuild and your favorite XML editor. Wix supports creating MSI installers, MSP patches, MSM Merge modules, Wix libraries and much more.
You should take a look at InstallJammer. Not only is it free, it's cross-platform and very easy to use. Most common actions don't require any scripting at all, but with a powerful scripting language underneath the hood, you can make an install do just about anything you want.
If all you want is a basic installer to install your application, you can have it built in a matter of minutes from the first time you start it up. If you want something more powerful, the capabilities and documentation are excellent.
If you're not after an installer (which is doesn't sound like you are) Why not just write a program to do what you need?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I was looking at http://tldp.org/LDP/abs/html/why-shell.html and was struck by:
When not to use shell scripts
...
Mission-critical applications upon which you are betting the future of the company
Why not?
Using shell scripts is fine when you're using their strengths. My company has some class 5 soft switches and the call processing code and the provisioning interface is written in java. Everything else is written in KSH - DB dumps for backups, pruning, log file rotation, and all the automated reporting. I would argue that all those support functions, though not directly related to call-path, are mission critical. Especially the DB interaction. If something went wrong with the DB-interaction code and dumped the call routing tables it could put us out of business.
But nothing ever does go wrong, because shell scripts are the perfect language for stuff like this. They're small, they're well understood, manipulating files is their strength, and they're stable. It's not like KSH09 is going to be a complete rewrite because someone thinks it should compile to byte code, so it's a stable interface. Frankly, the provisioning interface written in Java goes wonky fairly often and the shell scripts have never messed up that I can remember.
I kind of think the article points out a really good list of the reasons when not to use shell scripts - with the single mission critical bullet you point out being more of a conclusion based on all the other bullets.
With that said, I think the reason you do not want to build a mission critical application on a shell script is because even if none of the other bullet points apply today, any application that is going to be maintained over a period of time will evolve to the point of being bit by at least one of the those potential pitfalls at some point.....and there isn't anything you are really going to be able to do about it without it being a complete do over to come up with a fix....wishing you used something more industrial strength from the beginning.
Scripts are nothing more or less than computer programs. Some would argue that scripts are less sophisticated. These same folks will usually admit that you can write sophisticated code in scripting languages, but that these scripts are really not scripts any more, but full-fledged programs, by definition.
Whatever.
The correct answer, in my opinion, is "it depends". Which, by the way, is the same answer to the converse question of whether you should place your trust in compiled executables for mission critical applications.
Good code is good, and bad code is bad - whether it is written as a Bash script, a Windows CMD file, in Python, Ruby, Perl, Basic, Forth, Ada, Pascal, Common Lisp, Cobol, or compiled C.
Which is not to say that choice of language doesn't matter. There are very good reasons, sometimes, for choosing a particular language or for compiling vs. interpreting (performance, scalability, capability, security, etc). But, all things being equal, I would trust a shell script written by a great programmer over an equivalent C++ program written by a doofus any day of the week.
Obviously, this is a bit of a straw man for me to knock down. I really am interested in why people believe shell scripts should be avoided in "mission-critical applications", but I can't think of a compelling reason.
For instance, I've seen (and written) some ksh scripts that interact with an Oracle database using SQL*Plus. Sadly, the system couldn't scale properly because the queries didn't use bind variables. Strike one against shell scripts, right? Wrong. The issue wasn't with the shell scripts but with SQL*Plus. in fact, the performance problem went away when I replaced SQL*Plus with a Perl script that connected to the database and used bind variables.
I can easily imagine putting shell scripts in spacecraft flight software would be a bad idea. But Java or C++ may be an equally poor choices. The best choice would be whatever language (assembly?) is usually used for that purpose.
The fact is, if you use any flavor of Unix, you are using shell scripts in mission-critical situations assuming you think booting up is mission critical. When a script needs to do something that shell isn't particularly good at, you put that portion into a sub-program. You don't throw out the script wholesale.
It is probably shell scripts that help take a company into the future. I know just from a programming standpoint that I would waste a lot of time doing repetitive tasks that I have delegated to shell scripts. For example, I know most of the subversion commands for the command line but if I can lump all those commands into one script I can fire at will I save time and mental energy.
Like a few other people have said language is a factor. For my short don't-want-to-remember steps and glue programs I completely trust my shell scripts and rely upon them. That doesn't mean I'm going to build a website that runs bash on the backend but I will surely use bash/ksh/python/whatever to help me generate the skeleton project and manage my packaging and deployment.
When I read thise quote I focus on the "applications" part rather than the "mission critical" part.
I read it as saying bash isn't for writing applications it's for, well, scripting. So sure, your application might have some housekeeping scripts but don't go writing critical-business-logic.sh because another language is probably better for stuff like that.
I would wager the author is showing they are uncomfortable with certain aspects of qualtiy wrt shell scripting. Who unit tests BASH scripts for example.
Also scripts are rather heavily coupled with the underlying operating system, which could be something of a negative thing.
No matter we all need a flexible tool to interact with os. It is human readable interaction with an os that we use; it's like using a screwdriver with the screws. The command line will always be a tool we need either admin, programmer, or network. Look at the window they even expanded on their Powershell.
Scripts are inappropriate for implementing certain mission-critical functions, since they must have both +r and +x permissions to function. Executables need only have +x.
The fact that a script has +r means users might be able to make a copy of the script, edit/subvert it, and execute their edited Cuckoo's-Egg version.