[Issue 8 drafts 0001813]: generic xargs description cleanups
The following issue has a PROPOSED RESOLUTION. == https://austingroupbugs.net/view.php?id=1813 == Reported By:kre Assigned To: == Project:Issue 8 drafts Issue ID: 1813 Category: Shell and Utilities Type: Error Severity: Editorial Priority: normal Status: Resolution Proposed Name: Robert Elz Organization: User Reference: Section:XCU 3 / xargs Page Number:3600-3603 Line Number:123177-8 123183 123184-6 123228-32 123233-7 123252-3 123263 123304-6 Final Accepted Text:https://austingroupbugs.net/view.php?id=1813#c6767 == Date Submitted: 2024-02-16 14:42 UTC Last Modified: 2024-04-18 16:25 UTC == Summary:generic xargs description cleanups == Issue History Date ModifiedUsername FieldChange == 2024-02-16 14:42 kreNew Issue 2024-02-16 14:42 kreName => Robert Elz 2024-02-16 14:42 kreSection => XCU 3 / xargs 2024-02-16 14:42 krePage Number => 3600-3603 2024-02-16 14:42 kreLine Number => 123177-8 123183 123184-6 123228-32 123233-7 123252-3 123263 123304-6 2024-04-18 16:24 geoffclare Note Added: 0006767 2024-04-18 16:25 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1813#c6767 2024-04-18 16:25 geoffclare Status New => Resolution Proposed 2024-04-18 16:25 geoffclare Resolution Open => Accepted As Marked ==
[Issue 8 drafts 0001813]: generic xargs description cleanups
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1813
==
Reported By:kre
Assigned To:
==
Project:Issue 8 drafts
Issue ID: 1813
Category: Shell and Utilities
Type: Error
Severity: Editorial
Priority: normal
Status: New
Name: Robert Elz
Organization:
User Reference:
Section:XCU 3 / xargs
Page Number:3600-3603
Line Number:123177-8 123183 123184-6 123228-32 123233-7 123252-3
123263 123304-6
Final Accepted Text:
==
Date Submitted: 2024-02-16 14:42 UTC
Last Modified: 2024-04-18 16:24 UTC
==
Summary:generic xargs description cleanups
==
--
(0006767) geoffclare (manager) - 2024-04-18 16:24
https://austingroupbugs.net/view.php?id=1813#c6767
--
Interpretation response
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.
Rationale:
-
None.
Notes to the Editor (not part of this interpretation):
---
On page 3600 line 123176, change:
the application shall ensure that arguments in the standard
input are delimited by unquoted characters, unescaped
characters, or characters
to:
the application shall ensure that arguments in the standard
input are delimited by characters that are neither quoted nor
escaped, or by unescaped characters
After page 3600 line 123183, add two bullet items:
Quoting and escaping characters shall not be included in the arguments
passed to utility. Escaped characters shall be included in
the arguments.
It shall be an error if an attempt is made to quote a
character.
On page 3601 line 123231, change:
or {LINE_MAX} if there is no −s option
to:
or the default command line length if there is no −s
option
On page 3601 line 123232, change:
The last iteration has fewer than number, but not zero,
operands remaining.
to:
The last iteration has fewer than number operands
remaining, or zero arguments were read from standard input (and the
-r option is not specified).
On page 3602 line 123263, change:
The name of the utility to be invoked, found by search path
using ...
to:
The name of the utility to be invoked. If the name does not
contain a character, the utility shall be found by search path
using ...
On page 3603 line 123302, change:
If the −t option is specified, the utility and its
constructed argument list shall be written to standard error, as it will be
invoked, prior to invocation.
to:
If the −t option is specified, the utility and its
constructed argument list, with a character preceding each argument
and a terminating , shall be written to standard error, as it will
be invoked, prior to invocation. Implementations may insert quoting and
escaping characters in the output produced by -t such that the
output (minus the utility name) can be unambiguously used as input to a
subsequent xargs command and result in the same constructed argument
list.
On page 3603 line 123304, change:
a prompt of the following format shall be written (in the POSIX
locale):
"?..."
at the end of the line of the output from −t.
to:
a prompt shall be written at the end of the line of the output
from −t. In the POSIX locale, the format of the prompt shall be:
"?..."
Issue History
Date ModifiedUsername FieldChange
==
2024-02-16 14:42 kreNew Issue
2024-02-16 14:42 kreName => Robert Elz
2024-02-16 14:42 kreSection => XCU 3 / xargs
2024-02-16 14:42 krePage Number => 3600-3603
2024-02-16 14:42 kreLine Number => 123177-8 123183
123184-6 123228-32 123233-7 123252-3 123263 123304-6
2024-04-18 16:24 geoffclare Note Added: 0006767
==
[Issue 8 drafts 0001813]: generic xargs description cleanups
The following issue has been SUBMITTED.
==
https://austingroupbugs.net/view.php?id=1813
==
Reported By:kre
Assigned To:
==
Project:Issue 8 drafts
Issue ID: 1813
Category: Shell and Utilities
Type: Error
Severity: Editorial
Priority: normal
Status: New
Name: Robert Elz
Organization:
User Reference:
Section:XCU 3 / xargs
Page Number:3600-3603
Line Number:123177-8 123183 123184-6 123228-32 123233-7 123252-3
123263 123304-6
Final Accepted Text:
==
Date Submitted: 2024-02-16 14:42 UTC
Last Modified: 2024-02-16 14:42 UTC
==
Summary:generic xargs description cleanups
Description:
Since "xargs" has "been in the news" recently...And while this issue
is
specified to apply to Issue 8 Draft 4 (which is where the page/line
numbers
are from) I would assume it would eventually be moved to Issue 8, after it
is published, and probably be considered for Issue 8 TC 1.
Most of this is just text that should be worded better, but there are a
few omissions that ought to be included.
Lines 123177-8 - two different issues here. First, arguments are said
to be delimited by an alternation of 3 terms - unquoted , unescaped
or newline. The problem is that nothing quoted can be escaped,
and nothing escaped can be quoted, hence any that appears is
either
an unquoted or an unescaped and hence is a delimiter
character
according to that definition.
Second (same lines, but continuing perhaps) we have quoting, and escaping,
but nothing here actually says that the quoting " or ' chharacters, or the
excaping \ character are removed from the arg text - which is what I
assume
should happen, ie: in "abc def'"'ghi\jkl'\ m I would assume the argument
string is to be abc def'ghi\jkl m with the quoting and escaping
characters removed. But nothing says that, one could also read the text
as including those chars in the arg string, with the quoting or escaping
simply avoiding enclosed characters from being delimiters (and
quoted or escaped quote or escape characters from being quote or escape
characters).
Line 123183 "Any unquoted character" can be escaped, must include
as that's certainly a character, and isn't allowed to be quoted
(incidentally
nothing says what is to be done if a appears after an initial
opening quote before its companion closing quote - that might be intended
to
be treated as an error, or the might just terminate the quoting,
or the might just be a single unquoted character (which would be
a delimiter if -0 is not used) in the middle of otherwise quoted text, so
'abc
def'
would be two args, "abc" (and any invisible here following chars),
and those leading chars followed by "def". Unlikely, but
possible.
That was a side issue ... for line 123183, the issue is what does an
escaped
mean - at line 123178 it doesn't say that only non-escaped
chars are delimiters, all characters are,. About all I can see
about escaped is that the results are unspecified if the eof
string
follows one of those. I might guess that an escaped is intended
to
be removed from the input (both the escape and the but at the
minute
I don't see where anything says that.
Lines 123228-32: In the first bullet point, if -s is not specified, then
if number generates a command line longer than LINE_MAX but shorter than
{ARG_MAX}-2048 then it seems to imply that less than number args must be
used, to keep the command line length shorter than LINE_MAX. Why? That
seems like a thinko, lines 123202-3 just say that the default command line
length is at least LINE_MAX - in most cases it will be considerably
larger.
Then, same lines, the second bullet point says that fewer args (that
number)
shall be used if the last iteration has fewer than number operands
remaining
(that makes sense) - but not if there are zero. A strict reading of that
would result in the interpretation that the last invocation in that case
must
be padded to have number args ... (no idea how to accomplish that) - but
that's clearly not what it intended to say. More importantly, if there
are
zero args remaining, the previous iteration wouild have been the last,
this
one would not exist. Normally - there's still the case where the last
iteration is the first iteration, and -r was not given. In that case,
one
would assume that the utility should be run with no args (as it would if
there
