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 2025709 - /etc/profile.d/which2.sh incorrectly tests for ksh (and mksh, zsh) shells
Summary: /etc/profile.d/which2.sh incorrectly tests for ksh (and mksh, zsh) shells
Keywords:
Status: CLOSED ERRATA
Alias: None
Deadline: 2022-01-10
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: which
Version: 8.5
Hardware: Unspecified
OS: Linux
high
high
Target Milestone: rc
: 8.6
Assignee: Than Ngo
QA Contact: Jakub Haruda
URL:
Whiteboard:
: 2060919 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-11-22 19:26 UTC by tc.staff
Modified: 2023-08-03 01:39 UTC (History)
11 users (show)

Fixed In Version: which-2.21-17.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-10 15:25:05 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-103597 0 None None None 2021-11-22 19:28:53 UTC
Red Hat Product Errata RHBA-2022:2067 0 None None None 2022-05-10 15:25:08 UTC

Description tc.staff 2021-11-22 19:26:02 UTC 
Description of problem:

/etc/profile.d/which2.sh incorrectly tests for ksh (and mksh, zsh) shells, sets 'declare -f' instead of 'typeset -f'

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

2.21-16.el8


How reproducible:


Steps to Reproduce:
1. create a ksh script that uses #!/usr/bin/ksh
2. run script via cron

Actual results:

When the profiles get run you see

export: -f: unknown option

Expected results:

run script without trying to 'declare -f' in the which2.sh profile

Additional info:

The problem is here -

---
which_shell="$(cat /proc/$$/comm)"

if [ "$which_shell" = "ksh" ] || [ "$which_shell" = "mksh" ] || [ "$which_shell" = "zsh" ] ; then
  which_declare="typeset -f"
  which_opt=""
fi

---

/proc/$$/comm is the name of the command. If the script is "test.ksh" and called
directly it of course doesn't detect a ksh shell, it thinks the shell is "test.ksh".

Is kind of amazing how this passed automated tests? Maybe need to be some new tests.
Comment 4 tc.staff 2021-11-23 20:19:38 UTC 
A quick point of clarification: this isn't really cron related. If the script is passed to the interpreter (ksh <script>) then /etc/profile.d/which2.sh will behave as intended. However, if the script is marked as executable and invoked directly (./script) then /proc/$$/comm will contain the name of the script.


=======================
           
$ cat test.ksh
#!/bin/ksh
cat /proc/$$/comm

$ ./test.ksh
test.ksh

$ ksh test.ksh
ksh

=======================
Comment 5 Than Ngo 2021-11-23 21:08:09 UTC 
sadly i cannot reproduce your reported issue. It will help me a lot if you can provide working reproduce.

Thanks
Comment 6 tc.staff 2021-11-23 21:15:24 UTC 
You bet! 

The steps are below, including reinstalling which (our configuration management automatically replaces the file when it runs).

You'll need to source /etc/profile to invoke /etc/profile.d/which2.sh. You'd do this for non-interactive shells including cron tasks and cluster jobs in certain cases. For example, we use Lmod which requires setup via /etc/profile.d/ files.

Let me know if this helps and if you need any other info.




===================
[jstroik@c8test ~]$ sudo dnf reinstall which
Duo two-factor login for jstroik

...

Reinstalled:
  which-2.21-16.el8.x86_64                                                                                               

Complete!
[jstroik@c8test ~]$ vim test.ksh
[jstroik@c8test ~]$ chmod +x test.ksh
[jstroik@c8test ~]$ cat test.ksh
#!/bin/ksh
echo "about to source /etc/profile"
source /etc/profile
echo "Sourced /etc/profile"

[jstroik@c8test ~]$ ./test.ksh
about to source /etc/profile
./test.ksh[3]: .[70]: .[19]: export: -f: unknown option
Usage: export [-p] [name[=value]...]
Sourced /etc/profile
Comment 7 Than Ngo 2021-11-25 14:56:53 UTC 
thanks for the test, i can now reproduce this issue with above steps.
Could you please download https://than.fedorapeople.org/rhel8/which/which-2.21-17.el8.x86_64.rpm and test?

Thanks
Comment 9 tc.staff 2021-11-26 22:35:26 UTC 
Yes - I confirm I no longer receive the error. Thank you.

Looking at the updated which2.sh if you have an example script like this:

==============
#!/bin/zsh
source /etc/profile
cat /proc/$$/comm
eval ${which_declare}
==============

You will get different results if you ./test.zsh vs 'zsh test.zsh' due to the way /proc/$$/comm resolves.
Comment 19 Welterlen Benoit 2022-03-21 14:18:07 UTC 
*** Bug 2060919 has been marked as a duplicate of this bug. ***
Comment 21 errata-xmlrpc 2022-05-10 15:25:05 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 (which 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-2022:2067
Note You need to log in before you can comment on or make changes to this bug.