Bug 658190

Patch proposed to upstream:
http://bugs.gw.com/view.php?id=110

Fixed in current rawhide build - tcsh-6.17-10.fc15.

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
representative.

The patch has been accepted by upstream (6.17.03b).

    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.

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.

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.

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.

(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/ ]

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
EOF
chmod 755 test.csh

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

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

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.

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-2011-1686.html