Shell Programming and Scripting

Reminds me of my Visual Basic 4 times, before i knew how to create my own dll's, i made other exe's i then called using the console calls.

Still proud of my first ActiveX-DLL based application - T4C-Desktop (TPP to the 4th comming, mmorpg).
The 'desktop' was the container app to be started, using a custom 'ocx' for the menu lists, which contained entries according to the dlls downloaded.
Each dll had some 'fixed' strings to return, such as its group, so it could be loaded to the appropriate ocx list item, which would only show, if there was a an item to be displayed.
That way, i could add new groups, without to prepare the container app for it, by just saying so within an activex dll.
They also contained a 'resize' function, which was triggered by the resize of the container app, so the 'hwnd' - which was such an element too, and just written to a picturebox - could be replaced/udpated.

But in the end, in some way, it doesnt matter if one opens a subshell from within a script, or calls the console/shell - it is the same, though, not for the same purpose.

Hi sea

Yeah. I tried one time to do a command line app in Python. I had to have an answer for every possible event; mouse, keyboard, etc. I didn't want to code all that, so I finally settled on just running a normal shell and calling Python as needed. 10 times easier and faster. When the shell by itself is just too slow, it's nice to be able to call some outside help.

You do not "call" a shell.

You must fork a new process, exec it, let it run, wait for it to finish, reap it, and then return to whatever else you were doing. That's what system() does -- just to create a shell. And then the shell, once running, must do so again, to run whatever external command you asked it to do.

So you are running a thing which runs a thing and must wait for it to quit before you can wait for it to quit.

...which it does, having run the single, individual command you fed into backticks or system().

Imagine running full instances of Perl every time you needed to call uname in BASH even though uname has nothing to do with perl. That's the degree of pointless waste that happens when you write external-command-intensive programs in perl. It can be almost cripplingly wasteful.

Just using the shell in the manner it was meant to be used in the first place avoids quite a lot of round trip. Or you could write code in perl to the same effect, except that perl is pretty bad at that...

That's a nice feature, isn't it?

Code:

true && echo "this will print"
false && echo "this won't"
true || echo "neither will this"
false || echo "But this will"

sh had it first -- by decades.
You have backpedaled miles from your argument that shell code is somehow "unsafe" while perl code running plethoras of individual short-lived shells is somehow not.

Anyway. Would you agree that running awk thousands of individual times to process tiny amounts of data is a suboptimal use of it?

Perl is good at some things. I enjoy it for some things. Code like the OP is not an effective use of it.

(The "do something if condition" is a DEC Basic+ idiom that perl adopted)

Not to join the language wars - but the moment someone says such-n-such a language is best is naive at best. It really depends on the task at hand, time to implement, effort to implement, maintainability, efficiency, security, history, policy, etc. etc.

There is no best language.

I've seen scripts and programs that impressed the hell out of me with their cleverness and have taught me something new. I've also seen programming horrors that should never ever have seen the light of day. And everything in between.

The only words of advice I can give is - know your tools.

Mind you, this is something I have been involved with since my first assignment when I was given a choice to use COBOL, FORTRAN, or APL. Ended up with Basic+...

Looks like the OP is long gone however here is a good starting point for the bash version of that script. Again without the original data files and my limited knowledge of how split() and map() functions operate there may need to be tweaks on the policy reading part. I also leave the command options (-v -d) processing for the reader.

Code:

nbadmin="/usr/openv/netbackup/bin/admincmd"
output_dir="$PWD/EI_$(uname -n)"
policy_cmd="$nbadmin/bppllist"

function run_cmd() {
   status="$( $@ 2>&1 )"
   RC=$?
   [ $RC -ne 0 ]
}

$policy_cmd | while read policy
do
  policy_info=$($nbadmin/bppllist $policy -l)
  info=( $(grep "^INFO " <<<"$policy_info") )

  # not standard - ignore
  [ "${info[1]}" != "0" ] && continue

  # inactive - ignore
  [ "${info[11]}" != "0" ] && continue

  grep "^CLIENT " <<<"$policy_info" | while read ignore client ignore
  do
      if ping -c 1 -W 5 $client > /dev/null 2>&1
      then
          echo "$client not pingable" >&2
          continue
      fi
      ( echo "============= Version Check of $client ==================="
      bpgetconfig -t -A -g $client 2>&1
      echo "============= End Version Check of $client ===================" ) > $output_dir/version.$client

      if run_cmd $nbadmin/bpgetconfig -e "/$output_dir/exclude.$client.basic" "$client"
      then
         printf "$client bpgetconfig -exclude no policy failed with $RC\n%s\n" "$status" >&2
      fi

      if run_cmd $nbadmin/bpgetconfig -i "/$output_dir/include.$client.basic" "$client"
      then
         printf "$client bpgetconfig -include no policy failed with $RC\n%s\n" "$status" >&2
      fi

      grep "^SCHED " <<<"$policy_info" | while read ignore schedule ignore
      do
         if run_cmd $nbadmin/bpgetconfig -e "$output_dir/exclude.$policy.$client.$schedule" "$client"
         then
             printf "$client bpgetconfig -exclude with policy and schedule failed with $RC\n%s\n" "$status" >&2
         fi

         if run_cmd $nbadmin/bpgetconfig -i "$output_dir/include.$policy.$client.$schedule" "$client"
         then
             printf "$client bpgetconfig -include with policy and schedule failed with $RC\n%s\n" "$status" >&2
         fi
      done

  done
done

@ Corona688

The devils' advocate here.
You're right. Calling 'uname -r' is not a call to the shell. /bin/uname is a binary that has nothing to do with the shell. I should say 'system calls' instead.

Some say that, because Perl uses system calls, you might as well use Bash. That presumes that Linux binaries are Bash builtins. If you call uname or ping, or any other binary from Bash; is that different than calling one from Perl? Not at all. Bash scripts use system binaries the same way Perl does.

Bash just received a security upgrade. That speaks to that.
You dont have to fork a shell to run Linux binaries. Most returns go to stdout or stderr. Why would you need a shell. Does Awk require a shell fork? The standards guys would know more about that than I would.

I'm not back pedaling at all. Perl and other high level languages have libraries; huge volumes of reusable code to handle most anything. On big projects, they can save you hours, if not days of work. For the most part, they are tried and proven and secure, given there are no absolutes.

Again, I use the shell most of the time because I rarely ever do anything big in a coding sense. But if I did, I wouldn't use the shell. Speed alone is a factor. You mentioned Awk; 10 times faster than the shell.

In perl, it is. It runs an entire complete shell, for convenience, to run a single command.

That's is not what "system call" means.

It is a fork(), an exec(), and probably several dup()'s, pipe()'s, reads(), and write()s on the perl side -- then all the same on the bash side. And then, finally, uname gets to do the system call to get the system's name and prints it into that pipe.

Creating a process is actually a fair amount of work, which is why it's generally done as little as possible. Doubling the amount of work necessary for it is not efficient, which is why perl makes a poor shell replacement. That's not what "system call" means.

You have completely missed my point, besides.
Yes.

Yes, it is.

That is my point.

When you call an external command in perl, it just calls bash to do the real work for it, so that it nicely separates parameters and parses the way BASH has taught you to expect. Imagine if BASH had to call Perl to do anything, and you get an idea just how roundabout an arrangement this is.

You can avoid this by doing fork() and exec() instead of system(), but then you don't get all the nice things a shell does for you, like waiting for the process to finish and properly reaping it. You don't have to fork a shell, but you do have to fork. That's just how it works -- fork() to create a copy of yourself, then exec() to turn the copy into something else. In BASH, you fork once. In Perl you fork twice -- the first time, to create bash! The second time is bash fork()-ing then exec()-ing whatever. Exactly!

Whenever you do system() in perl, that uses a shell. For that matter, system() in lots of languages uses a shell -- including C and awk. That's just what system() means -- run this command in a native shell. In UNIX, that's a Bourne shell of some sort. In Windows, system() launches a Windows CMD interpreter.

Whenever you do ` ` in perl, that uses a shell too. Pretty sure Perl's popen-equivalent does also.

It's very inefficient if you're dealing with a lot of little commands. Twice the amount of work to use a process in Perl than BASH.

Why does it do this? Because BASH actually does a whole lot of things for you, to the point you haven't realized the problems it solves actually exist yet. Being able to say system("uname") instead of system("/usr/bin/uname"); works because BASH looks that up for you. To properly duplicate this and all the other little niceties the shell has taught you are "normal" would mean adding a lot more than you might expect.