This is a new development it seems and thank you for the update. Older versions (upon the knowledge of which i drew when i wrote the above) didn't, though.

Not always, but most times and, yes, that shaped my habits. It is not about "pure UNIX" versus "Linux", though, it is more about "every UNIX and every Linux too". When i write scripts i write them with absolutely every possibility in mind and if i have only, say, Solaris and AIX to serve but i know something won't work that way in HP-UX i will try to find a way that will work there too. Otherwise chances are you are finished with the script and two days later HP-UX is introduced and you restart from zero.

If i have to deal with things which are different in every system i try to encapsulate them as much as possible. Most times i try to isolate the logic and use layer-functions which then only do the OS-dependent parts like this:

Code:

do_something ()
case "$OS" in
     AIX)
          <AIX-related stuff here>
          ;;

     SunOS)
          <SunOS-related stuff here>
          ;;

     .....
esac

Everything else is decided/processed/triggered/... above and finally the OS-dependent part is called.

Well, the work you talk about you have only once. Second, i try to write my scripts like any software developer writes his programs: as general (and generalised) as possible. As a freelancer i regularly change the customer and work in different surroundings. It often happened to me that i was asked to write a certain procedure for systems A, B, and C and i just smiled, took out a USB-stick and said "on this you'll find exactly that". I might have written it for systems D, E and F, but as i write as generalised and OS-agnostic as possible it usually works on A, B and C too or at least does so with minor changes. If it takes you 10 minutes to adapt a script you would have worked two weeks to create anew (because it took you two weeks to write it in first place) you know that the one day you spent making it as independent from the actual surroundings as possible was well invested. It was well invested not only for me but also the customer who got a flexible and extensible solution.

Before doing systems administration i was programmer and i write scripts the same way i wrote programs: with adaptability and maintainability in mind. If you have a 50-lines script it doesn't matter if you produce a well-written piece of software or a kludge. If your scripts hit and break the 1000-lines mark you better have your source-code under control because otherwise you will never get finished. Yes, i have several 1000-lines scripts doing things for me.

And the old if it was hard to write it should be hard to read (and even harder to understand) is a great source of amusement but once you stopped chuckling over it you do as it should be done.

As i said here we are essentially artists as "technics" is derived from the greek word for "art". A painting isn't finished when everything is covered with paint but when you - as the painter - feel that sense of accomplishment and satisfaction with what you did. A program (=script) will be finished not when it runs without an error but when it runs AND has that inherent (and hard to describe) quality of "rightness", is documented, has error handling, will be able to deal with all conceivable conditions and more. In one word, it is finished not when it is running but when it is "good".

The great sculptist Bernini, considered to be one of the greatest of all times didn't stop when the plaster was used up but when he thought there was nothing left to do on a statue. This was what made him "the Bernini" and what took him above other sculptors - not the number of works, not the amount of material used. Write your programs like you do any other art: put your everything, the essence of your being, into it and don't stop until you think you could make your whole existence depending on it.

bakunin