WG15 Defect Report Ref: 9945-2-121
Topic: shell


This is an approved interpretation of 9945-2:1993.

.

Last update: 1997-05-20


								9945-2-121

 _____________________________________________________________________________

	Topic:			shell
	Relevant Sections:	3.14.8


Defect Report:
-----------------------

	From: dgk@research.att.com
	Date: Wed, 3 May 95 23:21:32 EDT

I wish to ask for an interpretation request on two issues in the
Shell and Utilities standard, ISO/IEC 9945-2:1993 (ISO/IEC 9945-2:1993)
related to shell special builtins.

The first issue has to do with the output of readonly and export.
In section 3.14.8, page 155, lines 1549-1551, and again in
section 4.14.9, page 156, lines 1564-1566, the standard states,
"The shell shall format the output, including the proper
use of quoting, so that it is suitable for re-input to the
shell as commands that achieve the same ... results."

In section 3.14.8, page 155 line 1548, it lists the output
format as
	"export %s=%s\n", <name>,<value>
and in section 3.14.9, page 156 line 1563, it lists the output
	"readonly %s=%s\n", <name>,<value>

What should the output of a variable that has the readonly
or export attribute, but is unset be?  For, example with
	unset foo
	export foo
	export
will the line for foo be
	export foo=
or
	export foo

The former follows the explicit output format but violates
the rule that on input it will achieve the same result
since the former sets the value to the null string rather
than leaving the value unset.

I believe that the correct result is the latter
since the purpose of the -p option was to save
and restore shell environments. Therefore,
the standard should be amended to allow this
format when variable is unset.
	

The second issue is related to the trap builtin.  In section
3.14.13, on page 160, lines 1733-1734, the standard states
"... the argument actions shall be read and executed by the
shell when one of the corresponding conditions arise".

It isn't clear when these conditions arise.  In particular,
historical shells have treated ALRM, SEGV, and CHLD
specially.  The alarm signal is used internally in
historical shells (used to time retry on fork() failures)
so that ALRM signals sent by other processes are silently
ignored.  On some historical shells, the shell increases
the size of memory when it receives a SEGV signal rather
than executing the SEGV trap.  The CHLD signal is
used by some historical shells to keep track of its
child processes, some of which may be invisible to the
application.

The standard should add words that make it unspecified
or implementation defined as to when and if the ALRM, SEGV,
or CHLD conditions ever arise.

David Korn
research!dgk
dgk@research.att.com


Interpretation response
------------------------

For the first issue:
The text on page 156, lines 1564-1566, page 155, lines 1549-1551 are in
conflict and as such the standard is unclear on this issue, and no 
conformance distinction can be made between alternative implementations 
based on this.  This is being referred to the sponsor.

For the second issue:
The standard states the behavior for the trap builtin in the shell and
conforming implementations must conform to this.  However, we believe it 
is a defect, and does not match historic practice.  It is not obvious 
that a shell could be made to work given the requirements specified
by the standard at this time.  Therefore, the concerns raised about this 
are being referred to the sponsor.


Rationale
-------------
None.
Forwarded to Interpretations group: May 04 1995
Proposed resolution forwarded: Aug 11 1995
Finalized: Sept 12 1995