*Synopsis*: Korn shell 93 sometimes mishandles return value of its child process
CR 6887363 changed on Apr 3 2010 by <User 1-5Q-9201>
=== Field ============ === New Value ============= === Old Value =============
Root Cause Another Bug Fix
====================== =========================== ===========================
*Change Request ID*: 6887363
*Synopsis*: Korn shell 93 sometimes mishandles return value of its child process
Product: solaris
Category: shell
Subcategory: korn93
Type: Defect
Subtype: Functionality
Status: 7-Fix in Progress
Substatus:
Priority: 2-High
Introduced In Release: solaris_nevada
Introduced In Build: snv_128
Responsible Engineer: <User 1-5Q-9201>
Keywords: oss-request, oss-sponsor
=== *Description* ============================================================
Following construction sometimes ends with wrong return value.
56 echo $op | grep rand 2>&1 >/dev/null
57 if [ $? = 0 ]; then
58 randseq="rand${SEED}"
59 else
60 randseq="seq"
61 fi
Sometimes, the given result is "rand..." even when there is no "rand" word in
$op. This can be demonstrated with TSufs/SnapShots/Func test case which
excercises shown code quite often.
As it happens only sometimes, I suppose there is an race-condition in handling
return value from a child process.
*** (#1 of 1): 2009-10-01 15:38:27 GMT+00:00 <User 1-I30-737>
*** Last Edit: 2009-10-02 12:52:46 GMT+00:00 <User 1-I30-737>
=== *Public Comments* ========================================================
OpenSolaris ksh93 integration project leader Roland Mainz asks:
Does the problem go away if you apply the ksh93-integration update2
tarballs from
http://www.opensolaris.org/os/project/ksh93-integration/downloads/2009-09-22/
?
I am pretty much sure the update should kill such race-conditions...
*** (#1 of 6): 2009-10-02 21:46:47 GMT+00:00 <User 1-5Q-1267>
I'm afraid that it doesn't. I installed the tarball on my test box but the test
keeps failing.
# /bin/sh --version
version sh (AT&T Research) 93t+ 2009-09-09
*** (#2 of 6): 2009-10-05 10:39:13 GMT+00:00 <User 1-I30-737>
Roland says:
Grumpf...
1. ... is it possible that you have the shell option "pipefail" enabled
(e.g. what does $ set -o | fgrep pipefail # say ?) ?
2. If "pipefail" is not enabled then I need a reduced testcase to
reproduce the problem (I don't have SWAN access). I tried $ ksh93 -c
'while true ; do echo $op | grep rand 2>&1 >/dev/null ; if [ $? = 0 ];
then randseq="rand${SEED}" ; else randseq="seq" ; fi ; [[ "$randseq" !=
"seq" ]] && print -- "$randseq" ; done' # over the whole weekend without
success...
Finally:
In general the pipe construct with "echo ... | grep" wins the award for
being horrible inefficient. AFAIK this should be _much_ more efficient:
-- snip --
if [[ "$op" == *rand* ]] ; then
...
else
...
fi
-- snip --
If you need egrep pattern you can use:
-- snip --
if [[ "$op" == ~(E)egrep_pattern ]] ; then
...
else
...
fi
-- snip --
(note that blanks and other shell-special character in egrep_pattern
need to be escaped with '\' and anchors need to be specified with
'l'/'r' in the ~(mod) prefix, e.g. ~(Er)pattern means pattern with right
anchor, ~(El)pattern means pattern with left anchor, ~(Ei)pattern means
case-insensitive matching etc.)
(more details on demand, ~(mod) supports much more pattern systems (like
shell, perl etc. patterns))
*** (#3 of 6): 2009-10-05 15:30:22 GMT+00:00 <User 1-5Q-1267>
# set -o | fgrep pipefail
pipefail off
And I can't use the "if" constructs because the script needs to be backward
compatible with Bourne shell to be able to run on Solaris 9 and 10.
I'll try to craft a minimal test case.
*** (#4 of 6): 2009-10-06 07:08:36 GMT+00:00 <User 1-I30-737>
Glenn Fowler, in response to the last comment on
<email address omitted>, suggested:
(not shirking the duty to find the real problem)
how about
case $op in
*rand*) randseq="rand${SEED}" ;;
*) randseq="seq" ;;
esac
*** (#5 of 6): 2009-10-06 14:58:30 GMT+00:00 <User 1-5Q-1267>
I finally made a test case. Please find it attached.
There seems to be many things contributing to this issue.
*** (#6 of 6): 2009-10-15 15:18:53 GMT+00:00 <User 1-I30-737>
=== *Workaround* =============================================================
=== *Additional Details* =====================================================
Targeted Release: solaris_nevada
Commit To Fix In Build: snv_138
Fixed In Build:
Integrated In Build:
Verified In Build:
See Also: 6886525, 6939349
Duplicate of:
Hooks:
Hook1:
Hook2:
Hook3:
Hook4:
Hook5: <email address omitted>
Hook6: <email address omitted>
Program Management:
Root Cause: Another Bug Fix
Fix Affects Documentation: No
Fix Affects Localization: No
=== *History* ================================================================
Date Submitted: 2009-10-01 15:38:26 GMT+00:00
Submitted By: <User 1-I30-737>
Status Changed Date Updated Updated By
3-Accepted 2009-10-02 16:03:12 GMT+00:00 <User 1-5Q-6085>
7-Fix in Progress 2010-04-02 17:06:39 GMT+00:00 <User 1-5Q-9201>
=== *Service Request* ========================================================
Impact: Significant
Functionality: Primary
Severity: 2
Product Name: storage-tests
Product Release: v3
Product Build:
Operating System: osol_2009.06
Hardware: x86
Submitted Date: 2009-10-01 15:38:27 GMT+00:00
=== *Multiple Release (MR) Cluster* - 0 ======================================
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
