Anonymous | Login | 2024-10-15 00:02 UTC |
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 | |||||||
0001813 | [1003.1(2024)/Issue8] Shell and Utilities | Editorial | Error | 2024-02-16 14:42 | 2024-07-24 14:33 | |||||||
Reporter | kre | View Status | public | |||||||||
Assigned To | ||||||||||||
Priority | normal | Resolution | Accepted As Marked | |||||||||
Status | Interpretation Required | |||||||||||
Name | Robert Elz | |||||||||||
Organization | ||||||||||||
User Reference | ||||||||||||
Section | xargs | |||||||||||
Page Number | 3600-3603 | |||||||||||
Line Number | (several) | |||||||||||
Interp Status | Approved | |||||||||||
Final Accepted Text | Note: 0006767 | |||||||||||
Summary | 0001813: 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 <blank>, unescaped <blank> or newline. The problem is that nothing quoted can be escaped, and nothing escaped can be quoted, hence any <blank> that appears is either an unquoted <blank> or an unescaped <blank> 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 <blank> 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 <newline> as that's certainly a character, and isn't allowed to be quoted (incidentally nothing says what is to be done if a <newline> appears after an initial opening quote before its companion closing quote - that might be intended to be treated as an error, or the <newline> might just terminate the quoting, or the <newline> 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 <blank> chars), and those leading <blank> chars followed by "def". Unlikely, but possible. That was a side issue ... for line 123183, the issue is what does an escaped <newline> mean - at line 123178 it doesn't say that only non-escaped <newline> chars are delimiters, all <newline> characters are,. About all I can see about escaped <newline> is that the results are unspecified if the eof string follows one of those. I might guess that an escaped <newline> is intended to be removed from the input (both the escape and the <newline> 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 was no -n option given) but that doesn't reconcile with the description of -n. Lines 123233-7: There should be an XREF to XBD 3.7 attached to "an affirmative response". [Aside: I expect this is just because this is how existing implementations behave, but if xargs is going to be opening /dev/tty to read the response to the prompt, why is it not writing the trace output and prompt string to /dev/tty instead of to stderr (which might have been redirected, in order to redirect stderr for the utility invocations). Very odd. Note this would be just for -p tracing/prompt, if just -t is used, stderr is fine.] Lines 123252-3: (-t) "Each generated command line shall be written to standard error just prior to invocation" - Really? The "command lines" generated are actually arg lists for exec, with the args terminated by nul bytes, and with no delimiting text of any kind. That is to be written to stderr? Amazing. Surely there should be spaces inserted between the args, and as it is a "command line" one would assume that a newline should also be appended. But what of <blank> characters that are not separators, should those be escaped or something, or is the user just supposed to guess? And what about embedded <newline> characters, which are possible if -0 was used. Line 123263: "utility" is "The name of the utility to be invoked, found by search path using the PATH"... Really? That's all that is permitted? No fully specified paths to the utility, no relative paths to "." (like "bin/command" - everything must be found by a search of PATH) ?? Lines 123304-6: "If -p is specified, a prompt of the following format shall be written (in the POSIX locale)" ... What's that supposed to mean. A stupidly literal reading might assume that the prompt is somehow intended to be written somewhere into the POSIX locale (whatever that might mean) but that's clearly not right, there's enough text elsewhere to make it clear the output goes to stderr - but what does that parenthesised phrase mean? Does it mean this specification only applies if the current locale is POSIX, and what happens for other locales is unspecified? Or perhaps it means that the current locale must be switched to POSIX to write that string (and then presumably switched back again). In any case it is not clear. |
|||||||||||
Desired Action |
For the first, perhaps change the alternation to just two terms, the first being something like "an unquoted and unescaped <blank>" (and then "or <newline>" just like now. For the quoting stuff, explicitly say that the quoting and escaping characters do not form part of the argument string (if they're quoted or escaped themselves they're not quoting or escaping chars, so nothing really needs to be said about that). No idea what escaped <newline> is intended to happen, but I'd guess something like "An escape <newline> pair of characters shall be removed from the input and not delimit an argument string", assuming that is what is to happen. Also say something, but here I have no idea what, about what happens if quoting is ongoing when a <newline> is encountered. For the paragraph at lines 123184-6, I'd write the paragraph starting at line 123176 something more like (here I'll abbreviate, not include every word, but I don't intend to change anything - just type less here!) If the -0 option is not specified, the application ... are delimited by a sequence of one or more unquoted and unescaped <blank> characters, or <newline> characters, adjacent delimiter characters shall be treated as a single delimiter (not produce empty arguments for the utility). Note that if the input is not empty and does not end in a <newline> the behaviour is undefined (because...). Quoting and escaping shall be interpreted as follows, with any quote or escape characters removed after they have been processed. (Then the three bullet points, with added text to explain what is to happen if a <newline> is (seems to be) quoted.) For the -n option, change the LINE_MAX in the first bullet point to be "the default line length as described above", and for the second bullet point, just say "for the last iteration, if there are fewer than number operands remaining" - no need to mention the zero case, if there are none left, then if there has already been an iteration, the previous one was the last (the one that used the final operand), there is no next one with zero operands - if there was no previous iteration, then we just do what we'd do with no -n (which depends upon -r). For lines 123233-7 add an xref to XBD 3.7. (Sure would be nice to change the output to go to /dev/tty - maybe that could at least be made an option?) For lines 123252 specify the format in which the lines are to be written, which cannot just be xargs internal form, but I have never used -t, so I have no idea what is actually done. For line 123263 - I suspect that the intent is to specify the same rules for finding the utility as execvp() (or execlp()) uses - perhaps simply say that, and xref it. (Not the shell command search rules, they're way too complex). That section xref's XBD 8 (page 167). The xref to add would be to page 867 here (in I8 D4). I can't suggest what to do with that "(in the POSIX locale)" as I have absolutely no idea what it is intended to mean. |
|||||||||||
Tags | tc1-2024 | |||||||||||
Attached Files | ||||||||||||
|
Issue History | |||
Date Modified | Username | Field | Change |
2024-02-16 14:42 | kre | New Issue | |
2024-02-16 14:42 | kre | Name | => Robert Elz |
2024-02-16 14:42 | kre | Section | => XCU 3 / xargs |
2024-02-16 14:42 | kre | Page Number | => 3600-3603 |
2024-02-16 14:42 | kre | Line 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 | => Note: 0006767 |
2024-04-18 16:25 | geoffclare | Status | New => Resolution Proposed |
2024-04-18 16:25 | geoffclare | Resolution | Open => Accepted As Marked |
2024-04-18 16:26 | geoffclare | Tag Attached: tc1-2024 | |
2024-06-17 08:19 | geoffclare | Project | Issue 8 drafts => 1003.1(2024)/Issue8 |
2024-06-17 09:17 | geoffclare | Note Edited: 0006767 | |
2024-06-17 09:18 | geoffclare | Note Edited: 0006767 | |
2024-06-17 09:19 | geoffclare | Section | XCU 3 / xargs => xargs |
2024-06-17 09:19 | geoffclare | Line Number | 123177-8 123183 123184-6 123228-32 123233-7 123252-3 123263 123304-6 => (several) |
2024-06-17 09:19 | geoffclare | Interp Status | => Pending |
2024-06-17 09:19 | geoffclare | Status | Resolution Proposed => Interpretation Required |
2024-06-21 11:48 | agadmin | Interp Status | Pending => Proposed |
2024-06-21 11:48 | agadmin | Note Added: 0006828 | |
2024-07-24 14:33 | agadmin | Interp Status | Proposed => Approved |
2024-07-24 14:33 | agadmin | Note Added: 0006840 | |
2024-07-25 03:59 | agadmin | Note Edited: 0006840 |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |