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 1842722 - csh doesn't set up the "$command" variable before sourcing in /etc/csh.cshrc any more (it used to).
Summary: csh doesn't set up the "$command" variable before sourcing in /etc/csh.cshrc ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: tcsh
Version: 7.9
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Jan Macku
QA Contact: Karel Volný
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-06-01 23:44 UTC by Thomas Gardner
Modified: 2023-10-06 20:21 UTC (History)
4 users (show)

Fixed In Version: tcsh-6.18.01-17.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-29 20:58:56 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:4043 0 None None None 2020-09-29 20:58:58 UTC

Description Thomas Gardner 2020-06-01 23:44:18 UTC
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 Jan Macku 2020-06-05 07:44:10 UTC
Bug is reproducible on fedora tcsh-6.22.02-1 as well.

Comment 8 Angelo Bonet 2020-06-24 23:19:37 UTC
Ran into this exact problem when moving from 7.7 to 7.8 -- which broke some of our tcsh infrastructure.

Adding to the confusion is the fact that --changelog for tcsh-6.18.01-16 doesn't seem to show all the patching that actually occurred (only shows one patch): e.g.  no mention of tcsh-6.18.01-delay-to-process-startup-files.patch.

Comment 9 Jan Macku 2020-06-25 07:43:37 UTC
Hi Angelo,
I'm sorry for inconvenience. Patch tcsh-6.18.01-delay-to-process-startup-files.patch was added as a part of backport of other fix from upstream.

This issue should be fixed in RHEL 7.9 tcsh-6.18.01-17

Jan

Comment 12 errata-xmlrpc 2020-09-29 20:58:56 UTC
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 (tcsh bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4043


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