WG15 Defect Report Ref: 9945-2-53
Topic: xargs -e eof_str


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

.

Last update: 1997-05-20


								9945-2-53

 _____________________________________________________________________________


	Topic:			xargs -e eof_str
	Relevant Sections:	4.72.2
	Classification: No change - unaddressed issue


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

SUBJECT:  ISO/IEC 9945-2-1993 Interpretation Request: xargs Default Behavior

I would like to point out an inconsistency between the description of the
xargs utility in section 4.72.2 and historical behavior of the utility's
-e eof_tr option as described in section E.4.72 and request that the next
revision of the standard clarify the intent by changing either the description
or the rationale.

Specifically, historic implementations of the xargs utility (as specified by
the System V Interface Definition, Issue 3 and by the X/Open Portability Guide
XSI Commands and Utilities, Issue 3) would stop processing when a line
containing exactly one underscore character was encountered on standard input.
The rationale for this section (POSIX.2-1993, volume 2, page 970, lines 8985-
8987) says that the -e eofstr option was not included in the standard because
this feature could easily be replaced by features provided by the sed utility.
If the only use of the -e eofstr option were to specify a line other than a
line containing exactly one underscore character as the end-of-file condition
and the POSIX.2 description of the xargs utility specified that a line
containing exactly one underscore character was to be interpreted as an end-
of-file condition, this would be true.  However, the POSIX.2 description of
the xargs utility (POSIX.2-1993, volume 1, page 480, lines 11100-11124) does
not allow for any way to specify an input line to be treated as an end-of-file
condition and the historical implementation's -e eofstr option could be used
not only to change the end-of-file string, but also to disable end-of-file
string processing.

When the standard behavior broke historic application practice, the rationale
in POSIX.2 usually points out the changed behavior.  Since it doesn't mention
this case, I'm inclined to believe that the breakage was unintentional.
Although I understand that the normative text in section 4.47.2 overrides the
informative rationale in section E.4.47, I hope the interpretations committee
will consider the intent and suggest that this breakage of historic practice
be remedied in the next revision of the standard.


(Donald W. Cragun)


WG15 response for 9945-2:1993 
-----------------------------------
The standard does not speak to this issue and hence does not
preclude implementations supporting this option.


Rationale for Interpretation:
-----------------------------------
Interpretations are not intended to constitute an alteration to the
standard.

Concerns about the wording of this part of the standard have
been forwarded to the sponsor.
 _____________________________________________________________________________