Bug 1845684

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.