Description of problem: Using grep in a ksh script after using a nested pipe in an exec statement can result in a false positive return code from grep later in the script. Version-Release number of selected component (if applicable): ksh-20100621-5.el5_8.1 How reproducible: Source of an example script, run multiple times and grep will report false positives: #!/bin/ksh # # Command seems irrelevant, using a pipe in the exec # statement results in a false positive on the grep # commands below # #echo foo | cut -c $(echo bar | grep bar) # FAILS echo foo | grep $(echo bar | sort -u) # FAILS #echo foo | grep $(echo bar) # OK # Greps grep foo /etc/passwd && echo "1: false positive?" grep foo /etc/passwd && echo "2: false positive?" grep foo /etc/passwd && echo "3: false positive?" grep foo /etc/passwd && echo "4: false positive?" grep foo /etc/passwd && echo "5: false positive?" grep foo /etc/passwd && echo "6: false positive?" Steps to Reproduce: 1. Save the above code in file test.ksh 2. Make it executable 3. Run with "/usr/bin/watch -n1 test.ksh" Actual results: False positive messages on screen, indicating "foo" is present in /etc/passwd. Also the messages aren't persistent, they can change from like 1,2,3,4,5,6 to 3,4 ony 6 or none. Expected results: No messages on screen as foo is not present in /etc/passwd. Additional info: Also tested under bash, no messages are reported. Also tried under RHEL6, no messages are reported. If you don't use a pipe in the exec statement the problem goes away. You can test this by uncommenting the OK line and comment the FAILS line in the example code.
To make it even more simple: host> ksh host> grep bar /etc/foo;echo $? grep: /etc/foo: No such file or directory 2 host> echo foo | grep $(echo foo | grep foo) foo host> grep bar /etc/foo;echo $? grep: /etc/foo: No such file or directory 0
Created attachment 674671 [details] repro case for ksh bug? running under vmware (RH 5) Tried this on: Slackware 14 (hardware): result 0 2 2 with no variations Puppy linux (hardware): result 0 2 2 with no variations Red hat 5.8 on vmware: result 0 0 0 or 0 2 0 or 0 2 2 or 0 0 2
Created attachment 674812 [details] 5.8 installed RPMS Was not able to reproduce on RH5.6 on vmware. After updating the virtual machine to RH5.8 the problem occurs again. Booted the 5.6 kernel in 5.8 but the problem persists. Added the output of "rpm -qa" on the RH5.8 system.
In contrary to this bug's title it's not only gr
In contrary to this bug's title (edited) it's not only the return code of grep which is incorrect, but return codes in general: [root@host ~]# ksh # /bin/false; echo $? 1 # foo | grep $(echo foo | grep foo) foo # /bin/false; echo $? 1 # /bin/false; echo $? 0 # /bin/false; echo $? 1 #
reproducible
Reproducible on RHEL5.9 as well: # cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.9 (Tikanga) # # ksh --version version sh (AT&T Research) 93t+ 2010-06-21 # # rpm -qa |grep ksh ksh-20100621-12.el5 # # echo foo | grep $(echo foo | sort) foo # /bin/false;echo $? 0 #
What do you mean by "as well"? AFAIK this is reproducible only in 5.9 and not in 6.4.
I noticed a RHEL5.9 release yesterday, the bug was discovered on RHEL5.8. So the issue is still reproducible in the newest RHEL5 release (5.9). It's not reproducible on RHEL6.4, that is correct.
Something fishy here. RHEL6 does not reproduce this, but RHEL6 ksh package rebuilt for RHEL5 does. Interesting...
Found anything yet? If it's not the KSH software it might be a library which is kind of worrying to me.
The difference is not in library, but in kernel. With kernel <= 2.6.31.12 it reproduces this problem. With kernel >= 2.6.32-0.14.rc0.git18 it works. I don't know what causes this difference yet. Using several (much) older kernels does not change reproducibility, so I guess it's not caused by any bug in kernel. Also I was unsuccessful with debugging this so far. Interesting that problem does not reproduce when I try to use strace.
All right then, I thought it was just me misinterpreting the strace output. Thank you for the update.
Found a bug in ksh. Here are test packages if you want to test them: http://mhlavink.fedorapeople.org/bz892206/
Looking good, not reproducible with the new package as far as I can tell.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1351.html