Bug 784510 - Fix regression in default $status value in case of lists/pipelines
Fix regression in default $status value in case of lists/pipelines
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: tcsh (Show other bugs)
6.2
All Linux
urgent Severity high
: rc
: 6.3
Assigned To: Roman Kollár
BaseOS QE - Apps
CHANGE
: Regression, ZStream
: 790740 (view as bug list)
Depends On: 638955 759132
Blocks: 798652
  Show dependency treegraph
 
Reported: 2012-01-25 03:28 EST by Vojtech Vitek
Modified: 2015-03-04 18:57 EST (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, the "anyerror" variable could be selected to set the tcsh exit value behavior. However, "anyerror" is a shell variable and therefore was not propagated to subshells, and could not globally affect csh scripts. This update modifies the tcsh exit value behavior to the default behavior of csh: the new "tcsh_posix_status" variable is now available instead of "anyerror" to allow behavior similar to the POSIX standard.
Story Points: ---
Clone Of: 759132
: 1025703 (view as bug list)
Environment:
Last Closed: 2012-10-09 08:41:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Opt-in POSIX-like error exit $status by $tcsh_posix_status variable set (5.00 KB, patch)
2012-02-24 10:20 EST, Vojtech Vitek
no flags Details | Diff
tcsh.spec patch to *alway* enable/disable the opt-in variable $tcsh_posix_status (3.45 KB, patch)
2012-02-24 10:29 EST, Vojtech Vitek
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Legacy) 40784 None None None Never

  None (edit)
Comment 5 Vojtech Vitek 2012-02-16 11:25:28 EST
*** Bug 790740 has been marked as a duplicate of this bug. ***
Comment 9 Vojtech Vitek 2012-02-24 10:20:21 EST
Created attachment 565613 [details]
Opt-in POSIX-like error exit $status by $tcsh_posix_status variable set
Comment 10 Vojtech Vitek 2012-02-24 10:29:55 EST
Created attachment 565621 [details]
tcsh.spec patch to *alway* enable/disable the opt-in variable $tcsh_posix_status

The only acceptable solution to *always* enable/disable the opt-in $tcsh_posix_status variable I could think of (even when run with `$tcsh -f' "fast" option), was to add /etc/csh.tcshrc TCSH-specific configuration file and read it every run.

Let's see what Ondrej (as an owner of the setup component) thinks about this solution.
Comment 12 Bob Arendt 2012-02-24 10:56:48 EST
Thank you for changing from "anyerror" to "tcsh_posix_status" as a setting name.

However, significantly changing tcsh to *always* read a setup file directly contradicts legacy behaviour in a negative way.  We and our customers have a massive installed base spanning many generations of RedHat operating under many different control authorities. If this change is implemented, a script (even using -f) can have different behaviours on different machines, unless *everybody* pays attention to this new quirk.  It's another recipe for failure.  This also subverts the intent of -f, to inhibit readying of any initialization files.

We use the -f feature not only for speed, but to guarantee a consistent default start-up settings. This prevents issues like https://bugzilla.redhat.com/show_bug.cgi?id=671289 being propagated into -f scripts as well.

The tcsh_posix_status *feature* is new.  tcsh is all about legacy support.  Please leave it as opt-in.  If someone writes a *new* script using -f and requires this non-tcsh behaviour, let them explicitly set it.  Please don't implement another opportunity for failure into tcsh.

POSIX requirements describe a Bourne shell (bash, ksh, zsh, ...).  csh was specifically designed to *not* be a Bourne shell.  See http://en.wikipedia.org/wiki/C_shell#Design_objectives_and_features .
Comment 13 Ondrej Vasik 2012-02-24 12:21:19 EST
I think Bob is right here... Tcsh should primarily focus on legacy support and having this new configuration file could only confuse admins. Therefore IMHO adding some new file and configuration file is not a good idea here.

Behaviour causing regression was introduced by minor release and change to correct one with optin via $tcsh_posix_status to more posix-like behaviour is a good compromise here (and still provides a chance .
Comment 15 Vojtech Vitek 2012-02-27 04:34:35 EST
Bob and Ondrej, thank you both for your opinions. I tried to make the opt-in feature as easy to use as possible for the users/customers who (already) require the POSIX-compliant behaviour as a default. However, I understand your concerns about a "new configuration file" that could rather mislead some people, especially when running a csh script with the '-f' option. Now I agree we should avoid such workarounds.
So let's just have the $tcsh_posix_status opt-in variable available for users and let them decide whether they want to enable it every run (and in every script they want to use it). I believe this should be the most satisfying solution regarding all interested parties.
Comment 18 Vojtech Vitek 2012-03-24 21:51:52 EDT
We are going to revert the tcsh exit value behaviour to the CSH default (as it used to work in tcsh for many years/decades). There will be $tcsh_posix_status variable available to opt-in the POSIX-like behaviour (as in bash, ksh, etc.).

$ false | true
$ echo $?
1
$ set tcsh_posix_status
$ false | true
$ echo $?
0
Comment 19 Eliska Slobodova 2012-05-22 11:41:16 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:
Previously, the "anyerror" variable could be selected to set the tcsh exit value behavior. However, "anyerror" is a shell variable and therefore was not propagated to subshells, and could not globally affect csh scripts. This update modifies the tcsh exit value behavior to the default behavior of csh: the new "tcsh_posix_status" variable is now available instead of "anyerror" to allow behavior similar to the POSIX standard.
Comment 20 Bob Arendt 2012-05-23 12:46:22 EDT
We're curious - why was this bug marked private?  Could you please open it up again?  We have product release information that references this bug, and it annoys our customers when they can't read the referenced bugzilla reports.  I don't see any reason for this bug to marked private;  Possibly this was a bugzilla error?

Thank you - we're glad that the errant behavior introduced in RHEL 6.2 has finally been corrected.
Comment 21 Jiri Pallich 2012-10-09 08:41:41 EDT
Since this is a parent bug of an issue that has already been released via Z-Stream (e.g. rhel-6.3.z), this bug is going to be CLOSED as CURRENTRELEASE.

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