Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000051 [1003.1(2008)/Issue 7] Shell and Utilities Comment Clarification Requested 2009-06-25 13:04 2020-01-20 15:04
Reporter geoffclare View Status public  
Assigned To ajosey
Priority normal Resolution Reopened  
Status Under Review  
Name Geoff Clare
Organization The Open Group
User Reference
Section sh
Page Number 3175
Line Number 105726
Interp Status ---
Final Accepted Text Note: 0000090
Summary 0000051: sh exit status not clear for built-in terminated by a signal
Description The EXIT STATUS section for the sh utility says:

    The following exit values shall be returned:

    [...]

    Otherwise, the shell shall return the exit status of the last
    command it invoked or attempted to invoke

and the EXIT STATUS section for the exit built-in utility says:

    The exit status shall be n, if specified. Otherwise, the value
    shall be the exit value of the last command executed, or zero if
    no command was executed.

It is not clear how these statements are supposed to be interpreted
in the case where the last command the shell invoked was terminated
by a signal. Section 2.8.2 talks about exit status on termination
by a signal, but from the context it appears only to apply to the
value of the $? special parameter:

    When reporting the exit status with the special parameter '?',
    the shell shall report the full eight bits of exit status
    available. The exit status of a command that terminated because
    it received a signal shall be reported as greater than 128.

I think the intention is that when the last command is terminated
by a signal, the shell's exit status should be the same value that
would have been reported in $? after the command. That is how
all of the shells I have tested behave, with two exceptions:

1. Some shells have an optimisation where, in some circumstances,
they execute the last command without forking (i.e. as if the script
had ended with "exec last_command"). When this is done, the parent
of the shell will see a wait status that looks as if the shell itself
was terminated by the signal:

$ echo 'kill $$' > killself; chmod +x killself
$ ksh -c './killself' &


[1] 6535
[1] + Terminated ksh -c './killself' &
$

If the shell needs to make use of the command's exit status, the
optimisation is not used:

$ ksh -c './killself && true' &
[1] 6538
$ ksh: 6539 Terminated
[1] + Done(143) ksh -c './killself && true' &
$

While the behaviour with this optimisation may be a little misleading
to the parent of the shell, the optimisation is a worthwhile feature,
and on balance I think the standard should be modified to allow it.

2. In ksh93 when a command is terminated by a signal, it assigns an
exit status of 256 plus the signal number. When the shell then tries
to use this as its own exit status, it gets truncated to 8 bits (thus
the exit status of the shell is the signal number):

$ ksh93 -c './killself; exit' &
[1] 22214
$ ksh93: line 1: 22216: Terminated
[1] + Done(15) ksh93 -c './killself; exit' &
$

$ ksh93 -c './killself && true' &
[1] 22218
$
[1] + Done(15) ksh93 -c './killself && true' &
$

I consider the exit status of 256+signum in ksh93, instead of
128+signum as in other shells, to be an undesirable misfeature.
As well as making the shell's exit status non-conforming as
discussed here, it also breaks "wrapper" scripts that execute other
commands after the one being wrapped:

wrapped_command "$@"
ret=$?
other_command
exit $ret

If wrapped_command is terminated by a signal, with ksh93 the exit
status of the wrapper script will be the signal number. With
other shells it will be 128+signum, which means that if the
wrapper script was executed from a shell, the value of $? in
that shell is the same as if wrapped_command had been executed
directly.

For these reasons, the proposed action below does not modify the
requirements on shell exit status to allow this second exception.
Instead it enforces the normal relationship between the shell's
exit status and the exit status of the last command by
requiring that when a command is terminated by a signal its
exit status is greater than 128 and less than 256, thus ensuring
that truncation does not occur. It also modifies XRAT C.2.8.2
which, unfortunately, encourages this misfeature.

Finally, the EXIT STATUS section for sh has some text about the
shell attempting to invoke the last command, which is missing
from the EXIT STATUS section for the exit builtin, and the text
in the RATIONALE section for the exit builtin should be in
APPLICATION USAGE.
Desired Action Change

    "Otherwise, the shell shall return the exit status of the last
    command it invoked or attempted to invoke (see also the exit
    utility in Section 2.14, on page 2334)."

to

    "Otherwise, the shell shall return the exit status of the last
    command it invoked or attempted to invoke (see [xref to 2.8.2]),
    unless the shell invoked the last command without forking, in
    which case the wait status seen by the parent process of the
    shell shall be the wait status of the last command the shell
    invoked. See also the exit utility in Section 2.14, on page 2334."

In the EXIT STATUS section for the exit builtin utility at
page 2347 line 74240 section 2.14, change

    "The exit status shall be n, if specified. Otherwise, the value
    shall be the exit value of the last command executed, or zero if
    no command was executed."

to

    "The exit status of the shell shall be n, if specified. Otherwise,
    the exit status of the shell shall be the exit status of the last
    command the shell invoked or attempted to invoke (see [xref to
    2.8.2]), or zero if the shell did not invoke or attempt to invoke
    any commands before executing the exit utility."

In the APPLICATION USAGE section for the exit builtin utility at
page 2348 line 74247 section 2.14, replace "None" with the text
from the RATIONALE section at line 74254.

In the RATIONALE section for the exit builtin utility at
page 2348 line 74254 section 2.14, replace the current text with
"None".

At page 2316 line 73066 section 2.8.2, change

    "When reporting the exit status with the special parameter '?',
    the shell shall report the full eight bits of exit status
    available. The exit status of a command that terminated because
    it received a signal shall be reported as greater than 128."

to

    "When a command is terminated by a signal, the shell shall assign
    it an exit status greater than 128 and less than 256. When
    reporting the exit status with the special parameter '?', the
    shell shall report the full eight bits of exit status."

At page 2302 line 72527 section 2.5.2, change

    "Expands to the decimal exit status of the most recent pipeline
    (see Section 2.9.2, on page 2318)."

to

    "Expands to the decimal exit status (see [xref to 2.8.2]) of the
    most recent pipeline (see Section 2.9.2, on page 2318)."

Cross-volume change to XRAT:
At page 3662 line 124576 section C.2.8.2, change

    "Historically, shells have returned an exit status of 128+n, where
    n represents the signal number. Since signal numbers are not
    standardized, there is no portable way to determine which signal
    caused the termination. Also, it is possible for a command to exit
    with a status in the same range of numbers that the shell would
    use to report that the command was terminated by a signal.
    Implementations are encouraged to choose exit values greater than
    256 to indicate programs that terminate by a signal so that the
    exit status cannot be confused with an exit status generated by a
    normal termination."

to

    "Historically, shells have returned an exit status of 128+n, where
    n represents the signal number. Since signal numbers are not
    standardized, there is no portable way to determine which signal
    caused the termination, and therefore the standard just requires
    that the exit status is greater than 128 and less than 256.
    It is possible for a command to exit with a status in the same
    range of numbers that the shell would use to report that the
    command was terminated by a signal. Earlier versions of this
    rationale suggested that implementations could avoid this problem
    by choosing exit values greater than 256 to indicate termination
    by a signal; however, shells which do this do not conform to the
    requirements of the EXIT STATUS section for the sh utility if the
    last command the shell invoked was terminated by a signal.
    The requirement to use exit values less than 256 does not affect
    portable applications as they already need to ensure they do not
    choose exit values greater than 128 for other purposes, since all
    versions of this standard have allowed the shell to use values
    greater than 128 to indicate termination by a signal."
Tags issue8
Attached Files

- Relationships
related to 0001150Applied 1003.1(2016)/Issue7+TC2 exit status of command substitution not properly specified 
related to 0001309Applied 1003.1(2016)/Issue7+TC2 Clarity needed for initial value of $? at start of compound-list compound statements 

-  Notes
(0000089)
Don Cragun (manager)
2009-06-25 13:07
edited on: 2009-06-26 06:29

 Originally reported by gwc:xxxxxxxxxxxxx
Mon, 9 Mar 2009 09:36:34 +0000
with Subject: Defect in XCU sh

Transcribed by Don Cragun from xcubug3.txt ERN 7

Submitter tag "gwc sh exit status"
(0000090)
Don Cragun (manager)
2009-06-25 13:11
edited on: 2009-10-09 16:01

 Interpretation response
------------------------
The standard states the requirements for sh exit status,
and conforming implementations must conform to this. However, concerns
have been raised about this which are being referred to the sponsor."

Rationale:
-------------
None.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------

The setrlimit and getrlimit functions in XSH should move from XSI to Base

Note as the rationale for the move:
These are being moved to the Base so that portable shells can be written
that can catch a signal that caused a subshell to exit while dropping a core
file, to relay the status without overwriting the core file.

Changes to XCU:

In the EXIT STATUS section for the sh utility (P&L in the aarvark header)
change

    "Otherwise, the shell shall return the exit status of the last
    command it invoked or attempted to invoke (see also the exit
    utility in Section 2.14, on page 2334)."

to

    "Otherwise, the shell shall terminate in the same manner as for
    an exit command with no operands, unless the last command the
    shell invoked was executed without forking, in which case the
    wait status seen by the parent process of the shell shall be the
    wait status of the last command the shell invoked. See the exit
    utility in Section 2.14, on page 2334."

In the DESCRIPTION section for the exit builtin utility at
page 2347 line 74214 section 2.14, change

    "The exit utility shall cause the shell to exit with the exit
    status specified by the unsigned decimal integer n. If n is
    specified, but its value is not between 0 and 255 inclusively, the
    exit status is undefined."

to

    "The exit utility shall cause the shell to terminate. The wait
    status of the shell shall be determined by the unsigned decimal
    integer n, if specified.

    If n is specified and has a value between 0 and 255 inclusive, the
    wait status of the shell shall indicate that it exited with exit
    status n. If n is specified and has a value greater than 256 that
    corresponds to an exit status the shell assigns to commands
    terminated by a valid signal (see [xref to 2.8.2]), the wait
    status of the shell shall indicate that it was terminated by that
    signal. No other actions associated with the signal, such as
    execution of traps or creation of a core file, shall be performed
    by the shell.

    If n is specified and has a value of 256, or greater than 256 but
    not corresponding to an exit status the shell assigns to commands
    terminated by a valid signal, the wait status of the shell is
    unspecified.

    If n is not specified, the wait status of the shell shall be
    determined as follows:

      * If the exit status the shell assigned to the last command it
        invoked or attempted to invoke was less than 256, the wait
        status of the shell shall indicate that it exited with the
        same exit status.

      * If the exit status the shell assigned to the last command it
        invoked was greater than 256, the wait status of the shell
        shall indicate that it was terminated by the same signal that
        terminated the last command. No other actions associated with
        the signal, such as execution of traps or creation of a core
        file, shall be performed by the shell.

      * If the shell did not invoke or attempt to invoke any commands
        before executing the exit utility, the wait status of the
        shell shall indicate that it exited with exit status zero."


In the EXIT STATUS section for the exit builtin utility at
page 2347 line 74240 section 2.14, change

    "The exit status shall be n, if specified. Otherwise, the value
    shall be the exit value of the last command executed, or zero if
    no command was executed."

to

    "Since the exit utility causes the shell to terminate, it does
    not return an exit status to the shell. See the DESCRIPTION
    for details of the wait status of the shell."

In the APPLICATION USAGE section for the exit builtin utility at
page 2348 line 74247 section 2.14, replace "None" with the text
from the RATIONALE section at line 74254.

In the RATIONALE section for the exit builtin utility at
page 2348 line 74254 section 2.14, replace the current text with
"See [xref to XRAT C.2.8.2]."

At page 2316 line 73066 section 2.8.2, change

    "When reporting the exit status with the special parameter '?',
    the shell shall report the full eight bits of exit status
    available. The exit status of a command that terminated because
    it received a signal shall be reported as greater than 128."

to

    "When a command is terminated by a signal, the shell shall assign
    it an exit status greater than 128. The exit status shall
    identify, in an implementation-defined manner, which signal
    terminated the command. When a command terminates normally, the
    exit status reported with the special parameter '?' shall
    represent the full eight bits of exit status."

At page 2302 line 72527 section 2.5.2, change

    "Expands to the decimal exit status of the most recent pipeline
    (see Section 2.9.2, on page 2318)."

to

    "Expands to the decimal exit status (see [xref to 2.8.2]) of the
    most recent pipeline (see Section 2.9.2, on page 2318)."

Cross-volume change to XRAT:
At page 3662 line 124582 section C.2.8.2, after

    "Implementations are encouraged to choose exit values greater than
    256 to indicate programs that terminate by a signal so that the
    exit status cannot be confused with an exit status generated by a
    normal termination."

add

    "However, the use of exit values greater than 256 poses a problem
    for the shell's own exit status. Historically this was the exit
    status of the last command invoked by the shell, but if the last
    command was terminated by a signal and was assigned an exit status
    greater than 256 by the shell, this value would be truncated to
    eight bits in the shell's exit status. Likewise truncation would
    occur with use of

        exit $?

    or

        ret=$?
        ....
        exit $ret

    in shell scripts. To avoid this truncation, shells which assign
    exit statuses greater than 256 are required to propagate the wait
    status of the last command to the shell's own wait status (by
    sending itself the same signal), and to handle exit values greater
    than 256 passed to the exit builtin by mimicking the wait status
    that would give rise to assignment of that exit status in the shell.
    Note that this requirement does not apply to signals that do not
    cause termination, such as SIGCHLD, since the shell can never
    actually assign a corresponding exit status greater than 256, and
    the requirement is worded in terms of this assignment."
(0004687)
geoffclare (manager)
2019-12-18 15:02
edited on: 2020-01-20 15:03

 Reopening because the instructions in the Notes to the Editor in Note: 0000090 regarding the getrlimit() and setrlimit() functions are unclear.

Specifically, should all of the RLIMIT_* constants in <sys/resource.h> become mandatory, or only RLIMIT_CORE? The stated rationale for moving these functions to Base only requires RLIMIT_CORE to be mandated; the others could remain XSI. If the other constants are mandated, then this will have wide ranging effects elsewhere in the standard, e.g. SIGXCPU and SIGXFSZ in <signal.h>, and all text relating to the file size limit that is currently shaded XSI will need to have the shading removed.

In addition, the changes to the exit builtin will need to be updated to incorporate changes from bugs 0001150 and/or 0001309.

- Issue History
Date Modified Username Field Change
2009-06-25 13:04 Don Cragun New Issue
2009-06-25 13:04 Don Cragun Status New => Under Review
2009-06-25 13:04 Don Cragun Assigned To => ajosey
2009-06-25 13:04 Don Cragun Name => Geoff Clare
2009-06-25 13:04 Don Cragun Organization => The Open Group
2009-06-25 13:04 Don Cragun Section => sh
2009-06-25 13:04 Don Cragun Page Number => 3175
2009-06-25 13:04 Don Cragun Line Number => 105726
2009-06-25 13:07 Don Cragun Note Added: 0000089
2009-06-25 13:11 Don Cragun Note Added: 0000090
2009-06-25 13:11 Don Cragun Reporter Don Cragun => geoffclare
2009-06-25 13:11 Don Cragun Status Under Review => Interpretation Required
2009-06-25 13:11 Don Cragun Resolution Open => Accepted As Marked
2009-06-25 16:38 Don Cragun Tag Attached: real bug in aardvark
2009-06-26 06:29 Don Cragun Note Edited: 0000089
2009-06-26 08:49 Don Cragun Final Accepted Text => Note 0000090
2009-06-26 09:31 Don Cragun Final Accepted Text Note 0000090 => Note: 0000090
2009-07-30 16:09 Don Cragun Tag Detached: real bug in aardvark
2009-08-11 16:22 Don Cragun Interp Status => Pending
2009-09-17 15:41 nick Interp Status Pending => Proposed
2009-10-09 16:01 ajosey Note Edited: 0000090
2009-10-09 16:01 ajosey Interp Status Proposed => Approved
2009-11-02 22:33 user83 Note Added: 0000275
2009-11-02 22:33 user83 Note Added: 0000276
2009-11-02 23:10 user83 Note Deleted: 0000275
2009-11-02 23:10 user83 Note Deleted: 0000276
2010-09-20 09:03 geoffclare Tag Attached: issue8
2019-12-18 15:02 geoffclare Interp Status Approved => ---
2019-12-18 15:02 geoffclare Note Added: 0004687
2019-12-18 15:02 geoffclare Status Interpretation Required => Under Review
2019-12-18 15:02 geoffclare Resolution Accepted As Marked => Reopened
2020-01-20 15:03 geoffclare Note Edited: 0004687
2020-01-20 15:03 geoffclare Relationship added related to 0001150
2020-01-20 15:04 geoffclare Relationship added related to 0001309

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker