Bug 2025709
| Summary: | /etc/profile.d/which2.sh incorrectly tests for ksh (and mksh, zsh) shells | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | tc.staff |
| Component: | which | Assignee: | Than Ngo <than> |
| Status: | CLOSED ERRATA | QA Contact: | Jakub Haruda <jharuda> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.5 | CC: | bwelterl, byodlows, ccheney, efedin, jcastran, jharuda, mkenjale, ngalvin, prjagtap, rhayden, than |
| Target Milestone: | rc | Keywords: | CustomerScenariosInitiative, Triaged |
| Target Release: | 8.6 | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | which-2.21-17.el8 | Doc Type: | No Doc Update |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-05-10 15:25:05 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: | |||
| Deadline: | 2022-01-10 | ||
|
Description
tc.staff
2021-11-22 19:26:02 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
=======================
sadly i cannot reproduce your reported issue. It will help me a lot if you can provide working reproduce. Thanks 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 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 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.
*** Bug 2060919 has been marked as a duplicate of this bug. *** 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 |