Shell Programming and Scripting

I believe the discrepancy is due to the inner subshells, i.e. $( ... ) appearing with the same ps output command line as their parent script with later ksh93. One way to filter them out would be to use their parent pid.

Everything you are seeing is what happens when shell scripts depend on shell implementation details which are not prescribed by any standard.

I don't use RHEL and I only have one version of ksh with which to test, but I'm almost certain that the differences that you see between the old and new system is due to a ksh version update and a change in the way those versions execute pipelines/subshells.

If you take a look at the posix standard, it specifies the details of the execution environment, but it says nothing regarding implementation. The reason the command substitutions often yield a number 1 greater than the value from the same command that is not part of a substitution is because the shell has forked another copy of itself to execute the pipeline, and that new copy has the same $0.

The reason you see that 0 in your most recent post is because the shell has most likely exec'd into one of the utilities in its final pipeline before the ps utility fetches the process data. If you add another command after that pipeline, you'll probably see the count remain at 1.

In any case, these scripts make unportable assumptions. Not only are they not portable between different shells, they are not even portable between different versions of the same shell (as you have no doubt noticed ).

The best course of action (unless there is a massively immovable obstacle in the way) would be to rewrite these to not depend on the low level implementation of the shell.

Regards,
Alister

---------- Post updated at 07:15 PM ---------- Previous update was at 06:19 PM ----------

I can reproduce that behavior with the following script (pswc.sh):

Code:

#!/bin/ksh

ktrace -tc -ip $$
echo $0
SCRIPT=${0##*/}
echo $SCRIPT
/bin/ps | grep -v grep | grep $SCRIPT
/bin/ps | grep -v grep | grep $SCRIPT | /usr/bin/wc -l

KSH Version:

Code:

$ ksh --version
  version         sh (AT&T Labs Research) 1993-12-28 p

Output:

Code:

# ./pswc.sh 
./pswc.sh
pswc.sh
 1388  p1  S+     0:00.01 /bin/ksh ./pswc.sh
       0

Also, the trace output confirms that by the time ps starts to read the process list data, all of the ksh instances are gone (exec'd into greps, ps, and wc).

There is nothing "wrong" here, except the expectations of the script.

Hope that helps,
Alister

P.S. I can attach the trace output, but I doubt it's of much interest. It's not a RHEL system (it's not even linux), and you can probably reproduce it yourself with strace (or whatever is the name of the linux equivalent of ktrace).

I agree. I do not like the way that the "developers" write their shell scripts. I'm going to recommend that they change the way they are doing it and move on. I think they were simply counting on an old bug in the previous version.

Thanks for all the feedback.

Not a bug but undefined behavior. The bug was in the script, not in the ksh implementation.

Reason is seem like pathces..Allright..let try as last

Code:

echo $0
SCRIPT=${0##*/}
echo $SCRIPT
echo "IFS=xx${IFS}xx"
echo "PS=$(which ps)"
echo "GREP=$(which grep)"
echo "PGREP=$(which pgrep)"
echo "WC=$(which wc)"
 
/bin/ps -ef | /bin/grep -v grep | /bin/grep $SCRIPT
/bin/ps -ef | /bin/grep -v grep | /bin/grep $SCRIPT | /usr/bin/wc -l
echo "-----------"
/bin/ps -ef | /bin/grep -v grep | /bin/grep -c $SCRIPT
/bin/ps -ef | /bin/grep -v grep | /bin/grep -c $SCRIPT > procx
echo "proc1=$(cat procx)"
echo "-----------"

or the simpler:

Code:

pgrep $SCRIPT | wc -l > procx
echo "proc1=$(<procx)"