Sorry, that is not a bug but a feature: as a means to fight spammers who occasionally swamped the forum with links for "goods of questionable reputation" (fake passports, viagra pills, ... take your pick) we took away the right to post links for users below a certain post count. Once you are over that threshold (and it is going to be soon) you can post links without problem. This way we drove the worst spammers away and with the rest we can deal. Sorry for this inconvenience, but there we foud no better alternative.

Thank you, i am glad i could be of help.

Thinking again, here are some other tips and a response to stomp:

First: yes, one needs a lot of discipline. It turns out that the "freedom" the shell grants you (like not having to declare your variables, etc.) is best not used at all. One should write shell as if it was just another high-level language (like C or FORTRAN - are there any others?). This is why i prefer Korn Shell over bash, why i always declare my variables before i use them and why i write like shell variables were as typed as C variables.

In C it is possible to create a string, use it as an integer and - if the value just happens to match - as a pointer thereafter. This "clever programming" usually gets you into deep kimchi sooner than later. The same is true for shell scripts. I think the "obfuscated C contest" is a funny pastime to show off your skills - but whatever you write professionally should be the direct opposite of that: clear, self-evident, easy to read.

Itmaywellbethatyoucanstilldecipherwhatiwritethisway but perhaps employing this style consistently would not help to make me your favourite author.

About the topic of scripting versus programming (high.level languages): both have their place. As a systems administrator you need all kinds of administrative scripts/procedures and because i like my procedures to be as reliant as possible probably 80% of my code deals with error handling and logging. If you have an environment with ~400 systems (my last project) and write a script to create user accounts you check:

- if the user already exists (and, in case it doesn't)
- if the user ID is already taken on that server
- if the user name is already taken
- if the parent directory for the intended HOME already exists
- if there is enough room to create the HOME
- add other possible problems here ad libitum....

And my script checks all these on every server before even attempting to create the account. A script doesn't need to be able to deal with all these problems, but if on server 347 the creation has failed i rather read a log entry of user name "foobar" already taken, cannot continue than "mkuser error: stop"

All the tasks above are easy to do in script and, after doing all these checks, writing a documentation in the header, etc., the final script (yes, i use this every day, upon request i'll post it) is about 550 lines long (i make heavy use of a self-written library of external shell functions, in bash these functions would add another ~1000 lines of code). But the same in some highlevel language would be more closely to 10k lines and would take several months to write. This was written in about 3 days.

It is, IMHO, not about the size of a programming project, but its scope, that will determine the best-suited language. Like nobody would write a bookeeping software in assembler (not any more) and nobody would write number-crunching programs in anything else than FORTRAN, nobody would write application programs in script or administrative scripts in any high-level language. Its just not the right tool for the task.

To sum up about script programming: take it serious. Take it as serious as you would write any other piece of software because that in fact it is. With a different scope and different means, but the principles of good software engineering apply here no less than in any other environment. Even more so because the language doesn't enforce any strict work so that you have to make up with discipline what the language lacks in strictness.

I already stressed to comment your code: declaring your variables gives you the opportunity to describe their contents, which i always find helpful. Consider this code:

Code:

#! /bin/yourshell

typeset    chLine=""                      # line to process
typeset -i iArrCnt=1                      # counter to current array element
typeset    fIn="/bla/foo/somewhere"       # default input file
typeset    fOut="/bla/foo/whatever"       # default output file

# main ()
... rest of code

You might not like the hungarian style notation i adopted and stuck with but suppose you get this script in hand and should change something: it might be helpful to understand immediately what in which variable is supposed to be. It is not relevant which standard you use - but use any one (even your own) and stick with it consistently.

My own style (but that is personal preference more than anything else and heavily influenced by old habits from years of programming in assembler and FORTRAN) is to declare all local variables at the start of each function, put comments at position 50 of the line and never let a line be longer than 80 characters if i can avoid it. I use 5 spaces indentation and write my loops and control-structures in one line:

Code:

while [ "$bla" = "$foo" ] ; do
     this "$bla"
     that "$foo"
done

case $bla in
     X)
          this X
          that Y
          ;;

     *)
          bla
          if [ -z "$whatever" ] ; then
               whatever
          else
               something ELSE
          fi
          foo
          bar
          ;;

esac

But it doesn't matter so much what you do as long as you do it consistently. Programming is about organising your thoughts in the strictest possible way and your code should show this organisation.

Finally: Unix programs should maintain some tenets of interoperability. For instance, your script:

Code:

#!/bin/bash
clear
srvice=("plexmediaserver" "plexconnect" "plexpy" "nzbdrone" "couchpotato" "headphones" "utserver" "qbittorrent-nox" "HTPC-Manager" "sabnzbdplus" "webmin");

for i in "${srvice[@]}";  do
   systemctl is-active $i > /dev/null 2>&1
   state=$(systemctl is-active $i >/dev/null && echo Alive || echo Dead)
   #state="${state/failed/inactive}"
   printf "%-18s : %-20s\n" "${i^}" "${state^}"
done

Suppose you would use this script in some sort of pipeline or with a redirection to a log file:

Code:

script.sh | ...
script.sh >/path/to/log 2>&1

Don't you think that clear-statement, as useful as it might be in interactive use, might maybe disturb the processing? I would leave that out for exactly this reason.

Another topic: strive to adhere to the POSIX standard as much as you can. This is sometimes cumbersome and bound to additional effort, especially when you use Linux, because there are lots of nice little extras in many commands that come in handy. Still, it might limit the usability of your script to a certain platform i you use the extensions this platform offers for the standard. But using the bare standard every time is oftenly rewarded when you take a script from platform X, copy it to a completely different platform and it runs without any change.

OK, enough for today and happy scripting.

I hope this helps.

bakunin