0001611: exit status from fg is either badly specified or is simply wrong

Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Category

Severity

Type

Date Submitted

Last Update

0001611

[Issue 8 drafts] Shell and Utilities

Editorial

Error

2022-10-29 10:53

2022-11-01 10:04

Reporter

kre

View Status

public

Assigned To

Priority

normal

Resolution

Withdrawn

Status

Closed

Product Version

Draft 2.1

Name

Robert Elz

Organization

User Reference

Section

XCU 3/fg

Page Number

2750

Line Number

91265-91268

Final Accepted Text

Summary

0001611: exit status from fg is either badly specified or is simply wrong

Description

The exit status from the fg (intrinsic) utility is specified as

     0 Successful completion.

(and >0 if an error occurred). At best this is simply inadequate,
as it doesn't say successful completion of what, which matters here.

At worst, it is to be interpreted as for other utilities, and means
the fg utility itself was successful.

That is useless and does not match the implementations of almost any shell
(ancient pdksh seems to act like that).

In all other shells, when I tested the following command sequence

    (sleep 10; exit 1) &
    fg %1 [using the appropriate job number in each case]
    echo $?

the result from that echo is "1" - that isn't indicating that the
fg command failed, it is the status of the job that the fg command
returned to the foreground.

That's important, as there is otherwise no way to obtain that status.
The fg command specification (lines 91226-7) correctly says:

    Using fg to place a job into the foreground shall remove its process
    ID from the list of those ``known in the current shell execution
    environment''; see Section 2.9.3.1 (on page 2338).

Not being known in the execution environment means that a subsequent "wait"
command cannot obtain the status (that's correct, wait never works for
foreground processes that have completed). If $? at that point were to
simply mean "the fg command moved job 1 into the foreground" (or that
that failed) then there is no alternative remaining.

[other shells here does not include bosh, which simply exited, perhaps
dumped core, for the version I have at the minute, it does include all
ash derived shells (I have to test, no idea about busybox, bash, yash,
mksh, ksh93, and zsh].

Desired Action

Change the whole EXIT STATUS section (lines 91265-8) to be something like:

EXIT STATUS
    If the fg utility successfully moved a job to the foreground, then
    its exit status shall be the exit status of that job, after the
    job has terminated.

    Otherwise the fg utility will exit with a status greater than 0.

Tags

No tags attached.

Attached Files

Relationships

duplicate of

0001254

Applied

1003.1(2016/18)/Issue7+TC2

"asynchronous list" description uses "command" instead of "AND-OR list"

Notes
(0006019) geoffclare (manager) 2022-10-31 16:39	This is already being fixed by bug 0001254, which changes the fg EXIT STATUS to: If the fg utility succeeds, it does not return an exit status. Instead, the shell waits for the job that fg moved into the foreground. If fg does not move a job into the foreground, the following exit values shall be returned: >0 An error occurred.

(0006020) geoffclare (manager) 2022-11-01 10:04	Closing as withdrawn, as per austin-group-l sequence 34967.

Issue History
Date Modified	Username	Field	Change
2022-10-29 10:53	kre	New Issue
2022-10-29 10:53	kre	Name	=> Robert Elz
2022-10-29 10:53	kre	Section	=> XCU 3/fg
2022-10-29 10:53	kre	Page Number	=> 2750
2022-10-29 10:53	kre	Line Number	=> 91265-91268
2022-10-31 16:39	geoffclare	Note Added: 0006019
2022-10-31 16:39	geoffclare	Relationship added	duplicate of 0001254
2022-11-01 10:04	geoffclare	Note Added: 0006020
2022-11-01 10:04	geoffclare	Status	New => Closed
2022-11-01 10:04	geoffclare	Resolution	Open => Withdrawn

Mantis 1.1.6[^]