Company-wide Scripting Languages (unix shell languages versus jython)

Caught the following post @ ‘the life of glenn’ about scripting languages

*Lately I’ve been thinking about how important it is for a company to standardize on a scripting language. We had some scripts that help us deploy our s
oftware on client machines. The problem is they rely on bash being in a certain location the machine running the script. If we write our scripts in a java
scripting language and take the language with us when we go to deploy the software it will solve all of our problems. Currently at work we have perl script
s, python scripts, groovy scripts, and of course the standard shell scripts.

I think for personal use on your own machine in the office you can use what ever you wish but scripts that others in the company use it should be standardi
zed. Just might thoughts after doing a hard run today.

Well, it comes down to what you and your administrators know. There’s always more than one way to skin a cat.

perl has it’s uses, bash definately has its uses, and even python/jython have their uses, as do csh, tcsh, zsh, etc.

Do i want to have to copy my scripts dependencies everywhere I want to run my script. Not really, at least with todays systems.

In this particular case (I know the details because I work with Glenn), the problem was because the original author of the bash scripts developed them on a
linux machine and we went to use them on a new solaris machine, where /bin/sh != bash of course. Switching the #! fixed our problems for the most part.
You have this same problem with perl scripts when perl is not installed where the scripts expect them.

The problem with saying you shouldn’t use bash or another shell scripting language and standardize on something like jython, is that unless you’re going to
make system calls, you’re eliminating all the useful unix command-line tools that are available. On the flipside, if you are making system calls, then yo
u’re depending on the availability of certain versions of the command-line tools being available (ie. gnu tools vs. traditional solaris tools) which could
potentially be a mistake onto its own.

If I want someone else to maintain a script (or heaven forbid execute it or make an on the fly modification), I can’t really expect them to learn a java sc
ripting language. It’s sort of a catch-22, if java script languages were available everywhere (let alone java being available everywhere), perhaps such a
thing would be viable. But until such time, we’re stuck with tradition.

So in the end, nice idea Glenn, but I don’t think I’ll be endorsing the change :)

dist-upgraded to hoary without a hitch

Even though I’m going to Mexico for two weeks tomorrow, I decided to lay it all out and dist-upgrade my perfectly fine installation of warty on my work lap
top.

I’m happy to report that it went off without a hitch. Just finished a few more upgrades and will restart X to see if anything breaks, but other than that,
a success.

Good job ubuntu maintainers!

Back from Boston, Off to Mexico

I haven’t been able to post very often lately.

I’ve been visiting a client in Boston for 3 of the past 4 weeks and just got back two days ago.

I’m packing up today to head to Vancouver, hop on a plane tomorrow morning, and get off in Cancun. Going to spend a couple weeks at a resort an hour or so
south of Cancun.

Should be quite nice and I’m looking forward to the break. I’ll have my laptop so we’ll see how bad work needs to get a hold of me.

I’ve brought my copy of better, lighter, faster Java to re-read, hibernate in action and J2EE Dev without EJB. We’ll see just how much time I dedicate to
reading and/or listening to podcasts on the zen micro.

Cheers!