Bug 784510

*** Bug 790740 has been marked as a duplicate of this bug. ***

Created attachment 565613 [details]
Opt-in POSIX-like error exit $status by $tcsh_posix_status variable set

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.

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 .

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 .

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.

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

    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.

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.

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.