step 1: move all that stuff into cvs / source control system of your choice.

step 2: install cygwin on all the machines (http://sources.redhat.com/ [redhat.com])

alternately: use ms's unix system services (go digging on the m$ website) theoretically this will give you a "real unix" running inside windows.

at least this way you don't have to spend as much effort porting your old tools.

Make python executable (with py2exe) on shared drive, linked from win desktops as shortcut and launch on startup.

said script has dedicated local directory like: c:\ourscripts\
and synchs everything from the network at launch. Script remains running and checks via xml-rpc for updates and will throughout the day get updates to particular files. If you do the xml-rpc check every minute, you'll have near-realtime distribution of cli scripts to windows clients.

I am assuming you have less than 1k people to do that with in your org. One server could easily handle it.

by the way, redhat autoupdate uses xml-rpc.

This has the advantage not to need any local machine deployments of software packages.

Let me know privately if you need this sort of solution built. Or ask the python mailing list.

just put all your scripts and whatnot into cvs, then write a nice little webservice interface to your cvs server and have your windows admin write a group policy to reference the URI of the script as a desktop icon via the Windows .NET framework and Active Desktop. The current/stable version is always called when the icon is executed and the user gets all the in-house widgets they need as part of the login process. All you have to do is manage your Active Directory and group membership.

i'm pretty sure he means caned. there was a pretty famous case a couple years back where an american kid (micheal something or other) littered and was sentenced to a caning. huge american indignation followed

Actually, that indicates that it is really an engineering company. Among people whose first interest is science and programming is only a tool to solve scientific problems, it is common to refer to programs and libraries that solve specific problems as "codes". It is also a good bet that if it's called "a code", it's written in FORTRAN. And due to their science education, the authors were probably oblivious about principles of good software engineering.

That's all ok except for the CVS part. Use subversion and you will have it right.

...he/she refers to source code as "codes".

Old-school FORTRAN types often refer to single-purpose batch programs, like FEA jobs, as "codes". If you look in engineering magazines, HPC vendors often promise to run your "codes" faster than ever, etc.

Simon Peyton Jones, a Microsoft researcher in England who does a lot of work on Haskell (for Microsoft?), has a cheat sheet that "summarises all the things I do to make my Win2k machine more useful to me."

www.research.microsoft.com/~simonpj/win32-cheat.ht ml [microsoft.com]

It's rather funny, as much of what he does is make the system more like Unix, with tools like:

• Emacs, ispell for Emacs, Emacs tags tables
• Latex
• A good Telnet client
• Cygwin
• Services for Unix
• CVS
• GHC (Glasgow Haskell Compiler)

He describes how to set things up so he can:

• Export Postscript from a Word, Excel, or Powerpoint document
• Include LaTeX equations in Powerpoint slides
• Draw a Powerpoint/Visio picture and include it in a LaTeX document
• Convert between Word and LaTeX
• Include typeset material from Postscript into a Powerpoint slide
• Include mathematical symbols in Word documents

And more. Useful stuff in general for when you're forced to work on Win machines.

I've seen the words 'codes' used quite frequently to refer to multipel variants of a given algorithm. This is especially the case with FEA analysis where there might there might be different versions of an algorithm depending on what type(s) of symmentry are exploited to simplify the problem and whether or not the analysis requires the use of complex numbers.

Sorry to burst your bubble, but referring to engineering programs as "codes" dates back at least to Fortran 66. It's still pretty common in the HPC world, and pretty much anywhere the focus is on getting engineering tasks done, and not on programming.