Bug 1842722

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 7 Reporter: Thomas Gardner <thgardne>
Component: tcshAssignee: Jan Macku <jamacku>
Status: CLOSED ERRATA QA Contact: Karel Volný <kvolny>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.9CC: angelotech, fsumsal, jamacku, kvolny
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: tcsh-6.18.01-17.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-09-29 20:58:56 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 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