4

Please Note: Portable as in portableapps.com, not the traditional definition. Originally posted on stackoverflow.com, asking here at another user's suggestion.

I'm a DBA and sysadmin, mostly for Windows machines running SQL Server. I'm looking for a programming/scripting language for Windows that doesn't require Admin access or an installer, needing no install process other than expanding it into a folder. My intent is to have a language for automation on which I can standardize.

Up to this point, I've been using a combination of batch files and Unix shell, using sh.exe from UnxUtils but it's far from a perfect solution.

I've evaluated a handful of options, all of them have at least one serious shortcoming or another. I have a strong preference for something open source or dual license, but I'm more interested in finding the right tool than anything else. Not interested that anything that relies on Cygwin or Java, but at this point I'd be fine with something that needs .NET.

Requirements:

  • Manageable footprint (1-100 files, under 30 MB installed)
  • Run on Windows XP and Server (2003+)
  • No installer (exe, msi)
  • Works with external pipes, processes, and files
  • Support for MS SQL Server or ODBC connections

Bonus Points:

  • Open Source
  • FFI for calling functions in native DLLs
  • GUI support (native or gtk, wx, fltk, etc)
  • Linux, AIX, and/or OS X support
  • Dynamic, object oriented and/or functional, interpreted or bytecode compiled; interactive development
  • Able to package or compile scripts into executables

So far I've tried:

  • Ruby: 148 MB on disk, 23000 files
  • Portable Python: 54 MB on disk, 2800 files
  • Strawberry Perl: 123 MB on disk, 3600 files
  • REBOL: Great, except closed source and no MSSQL or ODBC in free version
  • Squeak Smalltalk: Great, except poor support for scripting

---- cut: points of clarification ----

Why all the limitations?
I realize some of my criteria seem arbitrarily confining. It's primarily a product my environment. I work as a SQL Server DBA and backup Unix admin at a division of a large company. In addition to near a hundred boxes running some version or another of SQL Server on Windows, I also support the SQL Server Express Edition installs on over a thousand machines in the field.

Because of our security policies, I don't login rights on every machine. Often enough, an issue comes up and I'm given local Admin for some period of time. Often enough, it's some box I've never touched and don't have my own environment setup yet.

I may have temporary admin rights on the box, but I'm not the admin for the machine- I'm just the DBA. I've no interest in stepping on the toes of the Windows admins, nor do I want to take over any of their duties.

If I bring up "installing" something, suddenly it becomes a matter of interest for Production Control and the Windows admins; if I'm copying up a script, no one minds. The distinction may not mean much to the readers, but if someone gets the wrong idea I've suddenly got a long wait and significant overhead before I can get the tool installed and get the problem solved.

That's why I want something that can be copied and run in the manner of a portable app. What about the small footprint? My company has three divisions, each in a different geographical location, and one of them is a new acquisition. We have different production control/security policies in each division. I support our MSSQL databases in all three divisions. The field machines are spread around the US, sometimes connecting to the VPN over very slow links. Installing Ruby \using psexec has taken a long time over these connections. In these instances, the bigger time waster seems to be archives with thousands and thousands of files rather than their sheer size.

You could say I'm spoiled by Unix, where the admins usually have at least some modern scripting language installed; I'd use PowerShell, but I don't know it well and more importantly it isn't everywhere I need to work.

It's a regular occurrence that I need to write, deploy and execute some script on short notice on some machine I've never on which logged in. Since having Ruby or something similar installed on every machine I'll ever need to touch is effectively impossible because of the approvals, time and and Windows admin labor needed I makes more sense find a solution that allows me to work on my own terms.

Aaron
  • 159
  • 1
  • 1
  • 7
  • For the lazy, here is a link to the stackoverflow discussion: http://stackoverflow.com/questions/2135787/portable-scripting-language-for-a-multi-server-admin – MattB Feb 03 '10 at 15:13
  • Do you have access to a fileshare at each site? Could you not zip up one of your choices with thousands of files, put it on a share point at each location, and copy it from whichever one is closest whenever you need it? – Clinton Blackmore Feb 03 '10 at 22:38

8 Answers8

1

With today's storage capacity, why is your "manageable footprint" so small (and why does the number of files matter at all)? My personal preference has been Perl, which only has the drawback of size. In fact, if you're in a single AD, you can do an install of ActiveState Perl to a UNC path, and access that UNC path from any machine so you don't have to install anything at all on all of your other machines.

With Perl2EXE, you can package anything into an EXE but it's not elegant or size-efficient.

Also, except for your desired point of non-Windows compatibility, PowerShell would do, except for the requirement that it work without an installer. Honestly, you might as well consider it an optional part of the OS and just add it to your standard environment (if you have any control over the environment.)

So, those are my two suggestions.

Dennis Williamson
  • 60,515
  • 14
  • 113
  • 148
mfinni
  • 35,711
  • 3
  • 50
  • 86
  • I like the "add powershell to your standard environment" approach. There is also a built-on-mono version of powershell that might help with cross-platform capability. http://pash.sourceforge.net/ – MattB Feb 03 '10 at 15:54
  • 1
    +1 for Perl. (Stupid 15 character minimum) – John Gardeniers Feb 03 '10 at 18:51
  • I'll expound a bit on the source of those requirements in my question... I didn't want to go into great detail since most folks get past the first few sentences and a few bullet points before spacing out. This and a few other points of clarifications after the cut above... – Aaron Feb 03 '10 at 21:19
  • @Aaron - I still don't see anything explaining why you have the size restrictions that you do. Particularly, what does the number of files have to do with anything? Also, please explain a little further - is this for a single site where you control all the computers, or do you travel between sites? If it's the former, as I explained, you can install Perl to a single fileshare and run it from anywhere. Even if you travel, Perl can fit on a USB stick easily. – mfinni Feb 03 '10 at 21:55
  • @mfinni: had something to take care of, I appended a description of my situation and explanation to my question. – Aaron Feb 03 '10 at 22:11
  • OK, I see. You can work within the system though. Try this: Standardize on a tool, and ask the operations or production or infrastructure team to deploy it to all the machines that you might have to work on (and to add it to the standard build for future SQL machines.) If you choose PSH, you stand a good chance at getting it. Or just learn VBScript, since it's already there. – mfinni Feb 03 '10 at 22:17
1

I don't think it meets all your requirements (the SQL Server\ODBC aspect, which is clearly critical) but I have an ancient (it's date stamped 1996) Perlv4 exe that I carry everywhere with me, for whenever I just want to do something quick and nasty. 379k - 1 file, needs no installation, runs on every Windows OS I've tried it on.

Helvick
  • 19,579
  • 4
  • 37
  • 55
  • Definitely worth mentioning, though! May not be the answer to this particular question, but it would be a handy part of my toolkit. I'll google about for it- thanks! – Aaron Feb 03 '10 at 21:17
1

I'd say vbscript/jscript is your best bet for an existing 2003 environment. If you can tweak your specs a bit to allow installs, powershell is the way to go going forward, particularly as powershell is currently available and will be used going forward for sql management. If you really really want portability (and frankly it then means your scripting potential is limited to parsing strings from text files and filenames) then I'd say you next best option is perl. Perl does not need an install on windows to function. Note that you don't need unxutils if you just want unix commands, you just need to install the services for unix subsystem.

All that being said I think your premise is flawed. I can't think of a reason I would want to "standardize" on an automation language since the task requirements for *nix vs windows tasks will require vastly different coding types. Eg for many system tasks in windows you're going to use WMI calls. WMI is not available on *nix. (yes I know CIM is but it's not the same). Even the simple things like filename paths are going to be parsed and written differently. I would suggest using the best tool available for the job at hand rather than trying to beat the inevitably square peg into a round hole.

Jim B
  • 23,938
  • 4
  • 35
  • 58
0

Half tongue-in-cheek : Hey .. VB script comes with the OS, how much smaller does your footprint need to get?

Otherwise, I really, really recommend Ruby. Why do you need "a small footprint" ? I put Ruby on several Windows servers because it's just so darn handy -- and it does not require admin privileges (although that in itself is a big red flag as to what your purposes are, but let's skip over that).

Trevoke
  • 409
  • 3
  • 12
0

What about Portable autohotKey

do not go by the name, it is very good general automation scripting language. I believe it covers all the things you want.

AutoHotkey Command Reference

KAPes
  • 994
  • 4
  • 12
  • It's Windows-only, which is a limitation that he says he doesn't want. – mfinni Feb 03 '10 at 18:26
  • POSIX support isn't a must but a preference... but for my needs AHK is entirely outclassed by the likes of ruby, perl, python, tcl, lua, smalltalk, etc. I do use it on my desktop, though- thanks! – Aaron Feb 03 '10 at 21:14
0

Another vote for VBScript here; it can do pretty much all of your requirements; misses out on most of the "bonus points" though.

Maximus Minimus
  • 8,937
  • 1
  • 22
  • 36
0

Portable Python, definitely (I know you tried it :)

ΤΖΩΤΖΙΟΥ
  • 1,038
  • 1
  • 10
  • 18
0

So, here is my two cents about scripting. On production systems ... use what is there, windows 2003 - VBScript, UNIX bash/perl/python/whatever (personally i use a combo of bash and perl).

The possibility of introducing issues even if the interpreter claims 0 footprint is huge. Even if you just copied up an executable temporarily it really really should go through change management anyway.

Here is my thinking on that: I'm right there with your admins - less installed the better. Also if you really think hard about the tasks you are doing do you really have alot that would need to be maintained in multiple languages? Mostly scripting is task specific and hence OS/application specific.

I agree it would be nice to have one script(ing language) to rule them all type situation, but I think that you'll find you are able to get alot more done using the native language on the box.

Also, if you shove all your scripts into a version control system it makes things a little easier on you too. I've got a littel CVS server setup with collections for my Powershell, VBscript, bash, perl and php scripts.

Zypher
  • 36,995
  • 5
  • 52
  • 95