Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2057482

Summary: csh doesn't set up the "$command" variable before sourcing in /etc/csh.cshrc any more (it used to).
Product: Red Hat Enterprise Linux 9 Reporter: Karel Volný <kvolny>
Component: tcshAssignee: Lukáš Nykrýn <lnykryn>
Status: CLOSED WONTFIX QA Contact: Karel Volný <kvolny>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 9.0Flags: pm-rhel: mirror+
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-08-23 07:28:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Karel Volný 2022-02-23 13:20:56 UTC
This bug was initially created as a copy of Bug #1845684

I am copying this bug because: 
looks like this has once again slipped through the cracks - the test fails with tcsh-6.22.03-6.el9


This bug was initially created as a copy of Bug #1842722

I am copying this bug because the same problem seems to exist in RHEL8 version of tcsh.  I realize that tcsh was rebased for RHEL8, but I'm hoping that maybe convincing the upstream developers to bring this behavior back won't be too terribly difficult.


Description of problem:

I have a customer that is depending on having "command" variable set while files are being sourced in if the shell is invoked with the "-c" switch.  It worked in tcsh-6.18.01-15 (and previous --- according to the customer, it has worked this way fine for some time), but it broke in tcsh-6.18.01-16 .  I'm thinking it looks like it could be the tcsh-6.18.01-delay-to-process-startup-files.patch added in -16.

Version-Release number of selected component (if applicable):


How reproducible:

100%

Steps to Reproduce:

With a version lower than tcsh-6.18.01-16 put something like:

--->8------>8------>8------>8------>8------>8------>8------>8------>8---
$ cat /etc/profile.d/test.csh
if (! $?command) then
  echo '$command is not defined' > /tmp/csh.command.`date +%s`.$$
else
  if ("$command" == "")  then
      echo '$command is empty' > /tmp/csh.command.`date +%s`.$$
  else
      echo '$command =' $command > /tmp/csh.command.`date +%s`.$$
  endif
endif
--->8------>8------>8------>8------>8------>8------>8------>8------>8---

In some file in /etc/profile.d .  Note that you can't just echo to the screen, because the code that will invoke this script (/etc/csh.cshrc) does so like this:

--->8------>8------>8------>8------>8------>8------>8------>8------>8---
        foreach i ( /etc/profile.d/*.csh )
            if ( -r "$i" ) then
                if ($?prompt) then
                    source "$i"
                else
                    source "$i" >&/dev/null
                endif
            endif
        end
--->8------>8------>8------>8------>8------>8------>8------>8------>8---

so in the following tests, you won't get any output because it's being redirected to null...

Actual results:

Using tcsh-6.18.01-16:
--->8------>8------>8------>8------>8------>8------>8------>8------>8---
$ tcsh -c 'cat /tmp/csh.command.`date +%s`.$$ ; echo $command'
$command is not defined
cat /tmp/csh.command.`date +%s`.$$ ; echo $command
--->8------>8------>8------>8------>8------>8------>8------>8------>8---

Expected results:

Using tcsh-6.18.01-15:
--->8------>8------>8------>8------>8------>8------>8------>8------>8---
$ tcsh -c 'cat /tmp/csh.command.`date +%s`.$$ ; echo $command'
$command = cat /tmp/csh.command.`date +%s`.$$ ; echo $command
cat /tmp/csh.command.`date +%s`.$$ ; echo $command
$
--->8------>8------>8------>8------>8------>8------>8------>8------>8---

Or, from some different machine (this is the customer's use case):

--->8------>8------>8------>8------>8------>8------>8------>8------>8---
ssh -ltstusr rhel7boxen 'cat /tmp/csh.command.`date +%s`.$$ ; echo $command'
$command = cat /tmp/csh.command.`date +%s`.$$ ; echo $command
cat /tmp/csh.command.`date +%s`.$$ ; echo $command
--->8------>8------>8------>8------>8------>8------>8------>8------>8---

In other words, even though the $command variable does eventually get defined, it used to be defined before sourcing in the startup scripts, now it gets defined after.  The customer in question built some stuff that depends on this, and it seems to have been working for a long time, but in the latest tcsh, not so much.

The customer thinks it would be lovely to have this back somehow, if possible.

Comment 2 RHEL Program Management 2023-08-23 07:28:33 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.