A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1801 ====================================================================== Reported By: mohd_akram Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1801 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Resolved Name: Mohamed Akram Organization: User Reference: Section: xargs Page Number: 3600-3601 Line Number: 123162, 123252 Final Accepted Text: See https://austingroupbugs.net/view.php?id=1801#c6657. Resolution: Accepted As Marked Fixed in Version: ====================================================================== Date Submitted: 2024-01-25 21:39 UTC Last Modified: 2024-02-26 07:30 UTC ====================================================================== Summary: xargs: add -P option ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0001811 xargs: add -P option to FUTURE DIRECTIO... ======================================================================
---------------------------------------------------------------------- (0006686) kre (reporter) - 2024-02-26 07:30 https://austingroupbugs.net/view.php?id=1801#c6686 ---------------------------------------------------------------------- Re https://austingroupbugs.net/view.php?id=1801#c6685 You're right, there is no way to guarantee that multiple child processes actually run in parallel, or not without the participation of code within those processes anyway - but this is just another argument for fixing the language used, lest someone claim the standard is demanding unimplementable behaviour. Note that I am not attempting to have the standard force implementations to make actual parallel execution possible, the aim here is to fix the wording in the standard so that no-one can read it as potentially demanding anything like that. || I am not so sure that "It is clear that without -P it isn't allowed || to keep collecting args, I might have been mistaken there, but your test is of the wrong thing. A correct test would be more like (echo a; echo b; echo c; echo d) | { xargs -n1 -- sh -c \ 'sleep 1; echo "$0"; case "$0" in (b) exit 255;; esac'; read v; echo Read "$?" "$v"; } xargs clearly cannot control what happens to processes executing in a pipeline feeding its input, that "echo a; echo b; echo c" all run very quickly, place a\nb\nc\n into the pipe, and then "echo d >/dev/tty" runs, before whatever is on the right side of the '|' even starts is no surprise at all, what is there, xargs, or something else, makes no difference to this at all. However I was probably misreading what is in the standard as it is now, what it says is: and exit without processing any remaining input. which I was reading as meaning "without reading any more input", in much the same way as the shell's "read" builtin is not permitted to read more than a single record (termininated by the end delimiter, normally a \n) from stdin. But that's not what it says, it just says processing of the input is not permitted (and in the above test, the final "read" reads "EOF" after 'a' and 'b' are output by the xargs sh script - "c" and "d" were apparently read from the pipe by xargs, but never "processed". Since the only visible processing of the args (all that it is possible to observe externally) is when they are passed as args to an invocation of utility, it now seems obvious that there is no rule on what xargs can do (with or without -P) as preparation for the next invocation(s) to start, while waiting for an earlier one to complete. Lastly for here, you're right, the spec of what the arg can be is a nitpick, but so are all of my comments - the point is just to get the language in the standard to be precise as to what will work, and not leave anything to the "well that's obvious, it must be...." as it turns out that while there are sometimes things that are obvious to everyone, it turns out not infrequently that the obvious interpretation means different things - everyone agrees that there is just one possible meaning, but they differ on what that meaning is. We need to avoid that. There's very little in the standard that prevents extensions, so if toybox wants to allow integer args to have a scaling factor appended, that's fine. The point of the standard is that users (applications) cannot rely upon that working everywhere - the standard needs to be very clear on what can be relied upon (so if some implementation found a meaning for running 7.5 parallel invocations, and so implemented non-integral "maxprocs" that would be OK - but not something users can rely upon, if the spec says that "maxprocs" must be an integer > 0 (the -P 0 case is the subject of a different issue - negative values would be some different extension, perhaps). But if it doesn't say what the implementations must support, how is the user supposed to know what will work. Guess? Issue History Date Modified Username Field Change ====================================================================== 2024-01-25 21:39 mohd_akram New Issue 2024-01-25 21:39 mohd_akram Name => Mohamed Akram 2024-01-25 21:39 mohd_akram Section => xargs 2024-01-25 21:39 mohd_akram Page Number => 3600-3601 2024-01-25 21:39 mohd_akram Line Number => 123162, 123252 2024-02-15 16:47 geoffclare Relationship added related to 0001811 2024-02-15 16:52 Don Cragun Note Added: 0006657 2024-02-15 16:53 Don Cragun Status New => Resolved 2024-02-15 16:53 Don Cragun Resolution Open => Accepted As Marked 2024-02-15 16:55 Don Cragun Note Edited: 0006657 2024-02-15 16:55 Don Cragun Tag Attached: issue9 2024-02-15 16:59 Don Cragun Note Edited: 0006657 2024-02-15 17:01 Don Cragun Final Accepted Text => See https://austingroupbugs.net/view.php?id=1801#c6657. 2024-02-16 11:31 kre Note Added: 0006660 2024-02-21 00:20 gabravier Note Added: 0006670 2024-02-21 16:49 gabravier Note Added: 0006672 2024-02-25 06:26 kre Note Added: 0006675 2024-02-25 06:38 kre Note Added: 0006676 2024-02-26 01:11 gabravier Note Added: 0006685 2024-02-26 01:23 gabravier Note Edited: 0006685 2024-02-26 07:30 kre Note Added: 0006686 ======================================================================
