Bug 1011576

Summary: ksh, command substitution no longer works after a pipe
Product: Red Hat Enterprise Linux 6 Reporter: sorin <sserban>
Component: kshAssignee: Michal Hlavinka <mhlavink>
Status: CLOSED CURRENTRELEASE QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.4CC: brwillia, ken_nishimura, nobody, ovasik, redhat, sauchter
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-02-18 09:52:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description sorin 2013-09-24 14:56:25 UTC
Description of problem:

command substitution appears to not work when preceded by a "|" redirection


Version-Release number of selected component (if applicable):
Name        : ksh                          Relocations: (not relocatable)
Version     : 20100621                          Vendor: Red Hat, Inc.
Release     : 19.el6_4.4                    Build Date: Thu 16 May 2013 09:25:18 AM EDT

How reproducible:

try to use command substitution after a pipe, here's a silly example:

# echo blah | echo  $(hostname)

#

Steps to Reproduce:

1.run:
# echo blah | echo  $(hostname)
2. look at the empty (carriage return) output.
3.

Actual results:

blank output (command substitution doesn't work)

Expected results:
output should be what the command "hostname" would output on it's own

Additional info:

here's a more through silly example:
# echo $(hostname)
pchd
# echo blah ; echo  $(hostname)
blah
pchd
# echo blah | echo  $(hostname)

(variable expansion does work, it seems only command substitution does not work)

# echo blah | echo  $HOSTNAME  
pchd
# 

in rhel5:

[root@rhel5-test ~]# ksh
# echo blah | echo $(hostname)
rhel5-test
# 

note: this appears to be a side-effect of 927586, but this is just guessing, i have no proof or explanation (feel free to ignore this assumption)

the impact to the customer is significant, this is a major change in behaviour, and it breaks many of their existing (tested, productive) scripts

Comment 1 Michal Hlavinka 2013-09-24 15:08:39 UTC
reproducible in 6.4.z
works in rhel-6.5 update to be

Comment 10 Ken Poulton 2014-01-17 01:41:30 UTC
At Agilent we're being bitten by this bigtime since we updated to RHEL 5.10 over Xmas.  Numerous scripts are failing in ways that take hours to track down; one sysad script wrote junk in / on 40 systems.  Can we up the severity?

Comment 11 Ken Nishimura 2014-01-17 04:28:15 UTC
This seems to be related to the kernel.  Both ksh version 20100621-18.el5 and 20100621-12.el5 fail under 2.6.18-371.1.2.el5 and newer, while they work under 2.6.18-348.6.1.el5.  (Note, I did not check kernels between 348.6.1 and 371.1.2).

What changed?

Comment 12 Michal Hlavinka 2014-01-17 09:23:31 UTC
Beware this bug is for RHEL6. For RHEL5, there is different bug #1028504

Comment 13 Ken Poulton 2014-01-17 19:14:21 UTC
Yes, we are using RHEL5.
But I get 
   You are not authorized to access bug #1028504.

Comment 14 Michal Hlavinka 2014-01-21 12:46:05 UTC
I know. Some bugs are private because they can contain sensitive information.

If you are Red Hat customer, you should use proper support channel (https://access.redhat.com/home). Support team will monitor the bug for you and forward important information.

Comment 15 Michal Hlavinka 2014-01-21 12:49:11 UTC
This bug should be closed. The issue should be fixed in RHEL-6.5 ksh. If someone can reproduce this issue with ksh >= 20120801-10.el6, let me know. Otherwise I will close this bug in a few days.