Bug 1011576 - ksh, command substitution no longer works after a pipe
ksh, command substitution no longer works after a pipe
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ksh (Show other bugs)
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Michal Hlavinka
BaseOS QE - Apps
Depends On:
  Show dependency treegraph
Reported: 2013-09-24 10:56 EDT by sorin
Modified: 2015-08-02 20:01 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-02-18 04:52:31 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description sorin 2013-09-24 10:56:25 EDT
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:

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

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)
# echo blah ; echo  $(hostname)
# echo blah | echo  $(hostname)

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

# echo blah | echo  $HOSTNAME  

in rhel5:

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

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 11:08:39 EDT
reproducible in 6.4.z
works in rhel-6.5 update to be
Comment 10 Ken Poulton 2014-01-16 20:41:30 EST
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-16 23:28:15 EST
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 04:23:31 EST
Beware this bug is for RHEL6. For RHEL5, there is different bug #1028504
Comment 13 Ken Poulton 2014-01-17 14:14:21 EST
Yes, we are using RHEL5.
But I get 
   You are not authorized to access bug #1028504.
Comment 14 Michal Hlavinka 2014-01-21 07:46:05 EST
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 07:49:11 EST
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.

Note You need to log in before you can comment on or make changes to this bug.