Bug 1460950 - ksh kills itself with a signal if exit status is greater than 256
Summary: ksh kills itself with a signal if exit status is greater than 256
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ksh
Version: 7.4
Hardware: All
OS: All
medium
medium
Target Milestone: rc
: ---
Assignee: Siteshwar Vashisht
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On: 1369571 1471874
Blocks: 1716963 1719445
TreeView+ depends on / blocked
 
Reported: 2017-06-13 08:50 UTC by Siteshwar Vashisht
Modified: 2020-09-10 10:42 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1369571
: 1471874 (view as bug list)
Environment:
Last Closed: 2019-08-14 11:34:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Comment 2 Siteshwar Vashisht 2017-07-11 17:36:31 UTC
https://github.com/att/ast/issues/56

Comment 3 Siteshwar Vashisht 2017-07-11 23:08:57 UTC
Pull Request for this bug https://github.com/att/ast/pull/57

Comment 9 Red Hat Bugzilla Rules Engine 2017-07-25 12:20:19 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

Comment 10 Paulo Andrade 2019-04-24 14:56:40 UTC
The patch used in rhel8 and fedora is different from the one initially proposed.
But it references the clone of this report, at bz#1471874.

One RHEL7 customer is using a test package with ksh-20120801-posix-exit.patch
but would like to have it backported to RHEL7.

Is there any reasons for not having a backport? The current behaviour is at best
confusing, and triggers from time to time. It is not only an explicit exit,
but also if the last executed command in a script does not handle a signal, ksh
kills itself with the same signal.

Comment 11 Siteshwar Vashisht 2019-04-25 10:13:48 UTC
I have not backported the patch because it causes a behavior change. When shell kills itself with a signal, it's left to the parent process how does it interpret the exit status. For e.g. on rhel-7.6 follow these steps:

1. Start a bash process
2. Start ksh from bash
3. Execute `exit 257`.
4. Bash will interpret this status as 129.

```
$ bash
$ ksh
$ exit 257
Hangup
$ echo $?
129
```


now consider another example:


1. Start a ksh process.
2. Start another ksh instance from ksh.
3. Execute `exit 257`.
4. Ksh will interpret this as 257.

```
$ ksh
$ ksh
$ exit 257
Hangup
$ echo $?
257
```


Changing this behavior might break scripts and I would not want to ship such change in a minor release. That's why this patch has not been backported.

Comment 12 Siteshwar Vashisht 2019-04-25 10:20:02 UTC
Also, I have made this request on several other bugs and I am repeating it again. We are working to revive AT&T KornShell[1] and recently we made an alpha release[2]. I would like RHEL customers to try it out and provide us feedback. Packages for latest release can be found here[3] or you can subscribe to our copr repos[4] for latest development packages.

[1] https://github.com/att/ast
[2] https://groups.google.com/d/msg/korn-shell/7VAqQg1N5D8/XniWn__RBgAJ
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=34360564
[4] https://copr.fedorainfracloud.org/coprs/g/ksh/latest/

Comment 13 Paulo Andrade 2019-04-25 12:12:22 UTC
  Is there a chance some patch is added for choosing behaviour?
Like what was done for bz#1454804 ?

Comment 14 Siteshwar Vashisht 2019-07-03 12:03:05 UTC
>   Is there a chance some patch is added for choosing behaviour?
> Like what was done for bz#1454804 ?

Not unless it's causing some serious issues on customer end. We should avoid working around such issues with new configurations.

Comment 15 Siteshwar Vashisht 2019-08-14 11:34:59 UTC
Closing this as wontfix. See comment 11 and comment 14 for details.


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