Shell Programming and Scripting

Try

Code:

/[Ss]tate/

for the search pattern.

hi kamaraj,

you got it correct, what i actually want. but unfortunately script is not working. any other suggestions ?

---------- Post updated at 03:31 PM ---------- Previous update was at 03:22 PM ----------

Thank you Rudic !! It works as expected. Could you please also explain me the code ?

awk includes pattern matching capabilities similar to grep. So in lieu of grepping "State" to stdout and then printing the third field and then evaluating it, the proposal does all three actions in one go:

Code:

awk '
/[Ss]tate/ &&                                   # check input lines for the word "State" or "state"  AND
$3 != "0x0000"  {RES = 1}                       # check if field 3 deviates from pattern; keep result in variable RES
END             {print (RES?"not ":"") "OK"     # in the end, evaluate var. RES with "conditional operator" and print accordingly
                 exit RES                       # leave script with resp. exit code
                }
'

Could you quote your findings? I couldn't find anything which would back it up in the man pages of bash or zsh (I didn't check it for other shells). Well, even then, some limit likely applies (simply because the available memory is finite), but I agree that this limit might possibly be larger than the one which usually applies for the command line.

Still, exploiting this limit migh not be wise. I did some experimentation with this in bash and zsh, basically pasting the content of a huge file to the command line, with the result that after a certain size, my system started swapping (obviously because the shell tried to generate the whole command line in-memory, which makes sense) and in fact blocked the whole process (I killed it after a couple minutes). I would conclude that for processing large amounts of data, a solution based on xargs is safer than a command line expansion, even if it is "only" a for loop.

It is hard to prove a negative. The point is that the limit ARG_MAX in a C program applies to the arguments and environment variables that need to be passed to a new process image which happens when using C functions like the exec family of functions (including, but not limited to execl(), execle(), execv(), and fexecve()) and posix_spawn(). If your shell isn't written in C, whatever language you're using will still need to ask the kernel to create a new process image at some point, and when it does that it will be making the same system calls that the C library invokes to make the exec family of functions and the posix_spawn() function do their jobs so they would still be subject to the error return that would result in errno being set to E2BIG in a C program. It does not apply to shell compound commands like:

Code:

	for name [ in [word ... ]]
	do
		compound-list
	done
and:
	case word in
		[(] pattern1 ) compound-list;; |
		[[(] pattern[ | pattern] ... ) compound-list ;;]... |
		[[(] pattern[ | pattern] ... ) compound-list] |
	esac

and if statements, while loops, until loops, and function definition commands (none of which are run by the shell in a new process).

As far as the LINE_MAX limit, the standard is very clear in its description of the input files (i.e. shell scripts) read by the sh utility (which apply to any standards-conforming shell):
In practice, shell scripts are usually text files meeting LINE_MAX limitations, but that isn't due to shell restrictions; it is because the editors used to create shell scripts frequently fail if lines are longer than LINE_MAX. And, long lines are harder for humans writing scripts to understand.

I'm not saying you should never use xargs, but xargs has its own set of problems. And, I would never suggest using:

Code:

# Set IFS to just contain a <newline> character.
IFS='
' for line in $(cat file)
do	printf 'Process line: %s\n' "$line"
done

instead of:

Code:

while IFS='
' read -r line
do	printf 'Process line: %s\n' "$line"
done < file

(again with IFS set just for the read command to be just a <newline> character), which is much less memory intensive (if file can be large), but produces the same results (unless the shell runs out of memory while gathering arguments for the for loop).

Without a loop

Code:

if [ `db2 list tablespaces show detail | grep State | sort -u | wc -l` -eq 1 ]
then
  echo "OK"
else
  echo "not OK"
fi

Interesting approach. But wouldn't it have problems if

- there's more than one error state in the list
- the error state line is the one-before-last
- the error list has ONLY error states
?

How about using sort -u? And, isn't it uniq (not unique)?