Bug 658190 - Incorrect value of $status ($?) in case of pipelines
Incorrect value of $status ($?) in case of pipelines
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: tcsh (Show other bugs)
All Linux
high Severity medium
: rc
: ---
Assigned To: Vojtech Vitek
Branislav Náter
Depends On: 638955
Blocks: 697582
  Show dependency treegraph
Reported: 2010-11-29 11:00 EST by Vojtech Vitek
Modified: 2015-03-04 18:56 EST (History)
14 users (show)

See Also:
Fixed In Version: tcsh-6.17-13.el6
Doc Type: Bug Fix
Doc Text:
This package fixes the return value of the "status" (or "$?") variable in the case of pipelines and backquoted commands. The "anyerror" variable, which selects the behavior, has been added to retain backward compatibility.
Story Points: ---
Clone Of: 638955
Last Closed: 2011-12-06 12:01:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Comment 1 Vojtech Vitek 2010-12-21 09:31:20 EST
Patch proposed to upstream:
Comment 2 Vojtech Vitek 2011-01-04 11:03:22 EST
Fixed in current rawhide build - tcsh-6.17-10.fc15.
Comment 3 RHEL Product and Program Management 2011-01-07 10:36:39 EST
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
Comment 4 Vojtech Vitek 2011-01-18 05:39:02 EST
The patch has been accepted by upstream (6.17.03b).
Comment 16 Miroslav Svoboda 2011-08-30 06:40:18 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    New Contents:
This package fixes the return value of the "status" (or "$?") variable in the case of pipelines and backquoted commands. The "anyerror" variable, which selects the behavior, has been added to retain backward compatibility.
Comment 18 Angelo Bonet 2011-11-16 15:57:28 EST
Doesn't it seem a bit cavalier to call this a "bug" and change the behavior at this stage?  

This is the way tcsh has behaved on Redhat Enterprise Linux from 3 all the way up to 6.  So there are all these legacy tcsh scripts out there that have worked around the problem and are now going to potentially break.

I'm glad you at least introduced a shell variable that can set the behavior back, but you have to opt-in to the old behavior.  Seems like it would have made more sense to opt-in to the new behavior instead.
Comment 19 Bob Arendt 2011-11-16 17:55:38 EST
I've tested this fix using the tcsh-6.17-17.fc16.i686 from F16 updates-testing repo.  This fix breaks several csh scripts in our (and our partners) infrastructure chain.  I understand that "set anyerror" will give legacy behavior, but that doesn't propagate into sub-csh's invoked with the -f flag.  All of these scripts start with "#!/bin/csh -f" to avoid the overhead of re-running all the init-scripts in /etc/profile.d and ~/.*cshrc (and anything that they may source).  This *new* behavior (even though documented) should be off by default.  If needed, enable it with a csh variable.  Thank you for effort, but this well-intentioned change is potentially very destructive.

It looks like this will also hurt us in the RHEL 5.7 update release.

Please modify the default behavior of the this patch.
Comment 20 Bob Arendt 2011-11-21 22:37:25 EST
This patch changes the way that some logical statements are evaluated in tcsh.  The change adversely affects existing enterprise deployments.  It's unfeasible to us to re-evaluate the impact of this change on our existing scripts, not to mention those that our customers have developed and deployed.

This change make's RedHat's tcsh incompatible from any other deployed tcsh or csh.

This sort of change is totally inappropriate in the middle of an Enterprise release series and should be removed for consideration for RHEL 6.  This patch should also be reverted in the RHEL 5.7 (Bug #638955) for the same reasons.
Comment 23 Vojtech Vitek 2011-11-22 11:28:29 EST
(In reply to comment #18, comment #19, comment #20)
The thing is, that the correct behaviour is defined by POSIX (see
http://pubs.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_02_09_02  ). So, it's not just a 'random mistake' in man page.

Our primary target is to fix the wrong behaviour and prevent compatibility
issues with other POSIX-compliant shells (bash, ksh, resh etc.).

Upstream tcsh developer, who maintains tcsh since 1987, has also accepted the
changes (see http://bugs.gw.com/view.php?id=110 ), making this default
behaviour starting with TCSH version 6.17.05.

However, I understand your concerns and I'm willing to discuss possible changes
to fix your issue (reverting the changes / making the old behaviour default).

But please, beware that Bugzilla is not a customer support tool. I recommend
you contacting your support representative to escalate this request.
[ Global Support Services, http://www.redhat.com/support/ ]
Comment 24 Bob Arendt 2011-11-22 16:57:53 EST
We have filed this as Red Hat Support Case 00562858 several days ago.

The variable added for backwards capability can't be effectively applied against existing scripts.  Example:

Add to ~/.cshrc
set anyerror

Test script:
cat  > test.csh <<EOF
#!/bin/csh -f
cat no-exist | wc -l
echo $status
chmod 755 test.csh

Here's the legacy behavior that we expect:
122% ./test.csh
cat: no-exist: No such file or directory

Here's the new result:
125% ./test.csh
cat: no-exist: No such file or directory

The "set anyerror" in .cshrc (or any init file) is ignored
when the -f flag is applied (which bypasses all init files).
It's common practice for production csh scripts to assert
the -f flag to avoid unstable behavior due to interaction
with personal preferences in a user's ~/.cshrc file.

I don't believe that there's a strong need for posix compliance in tcsh.
If existing behavior is modified for the sake of posix compliance,
it should be opt-in using a variable like "posixcsh".  They any other
posix-conformance changes can be associated with the same variable.
Using a name like "anyerror" could be problematic, since it's not
unlikely that someone already uses that name in an existing script.
Comment 34 errata-xmlrpc 2011-12-06 12:01:54 EST
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.


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