To keep our shell scripts relatively consistent and avoid code reinvention, I've written a suite of shell functions that ends up in a sourceable file in /usr/local/etc. It contains functions for cleaning up temporary files and directories, set PATH appropriately based on OS, output the date in ISO8601 format, log to syslog, print out the local AD servers, etc.
I've written a similar, but more comprehensive, suite of Perl modules to support our Perl scripts, although it's broken up into separate files given the complexity of some of the uses (Grid Engine, Active Directory, etc.). Obviously if you work in a team of more than one, you'll want to make sure that these files are documented, and that you agree on things like function names and error handling. Skylar On Fri, May 13, 2016 at 6:41 AM, John Stoffel <j...@stoffel.org> wrote: > > This is one of those wonderful conversations to have at times. I > starting using Unix with Encore Multimax UMAX language, and for > whatever reason, fell into using csh as my shell, then tcsh because I > could edit the command lines. > > As my career progressed, I used alot of perl since being a SysAdmin is > all about parsing lots of random text strings and producing reports, > etc. I still use perl for alot of this because I know it so well. > > But over the years I've learned a bit of Ruby (until I ran straight > into the Big Global Lock problem of 2.x release and gave up on it and > Ruby on Rails for web programming). I'm back to perl. > > It's available widely, well known, and does the job. > > Haven't touched much python, mostly because I feel it's a huge step > backwards to goto indentation based scripting. I know some people > love it, and it's got some great packages and abilities. One of these > days I'll do more with it. > > But alot of my work also involves stupid simple sed/awk scripts, some > bash/csh loops to get stuff done, etc. And vi for some simple edits, > though I revert to emacs for bigger work, because I know it better. > > In any case, it's all down to what you and your co-workers feel > comfortable with and are willing to work with. It's also a matter > that after a while, the concepts are all the same, it just the syntax > that keeps screwing you up. > > I can read and understand python/ruby/bash/perl/whatever scripts > without too much trouble usually. Unless someone is an > uber-programmer and tries to use every last feature of the language > just to make things shorter or more concise, but at the expense of > clarity. > > Which brings up another comment, and that's layout and structure of > scripts. Keeping them well commented, and plain is in my opinion the > better way to go. How many times have you written a script, used it, > and then came back to it six months later and tried to remember how to > use it and how it works? > > I've started (finally!!!) to build all my scripts from a template.pl > script (my default big scripting language) that I wrote which gives > some some commmonly used helpers which should probably be in a > library, but whatever. In any case, it helps me document and keep > track of what I'm doing and easily add in the usage and help from the > get go. This is a huge help to the rest of the team when they try to > use my scripts. > > In summary, like the eternal war between editors and web browsers and > cars and motorcycles and coffee brands and whatever else two people > can argue about, it comes down to preference, comfort and team > interaction. > > > John > _______________________________________________ > Tech mailing list > Tech@lists.lopsa.org > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ >
_______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
