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: Under Review 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. ====================================================================== Date Submitted: 2024-01-25 21:39 UTC Last Modified: 2024-03-03 18:44 UTC ====================================================================== Summary: xargs: add -P option ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0001811 xargs: add -P option to FUTURE DIRECTIO... ======================================================================
---------------------------------------------------------------------- (0006702) gabravier (reporter) - 2024-03-03 18:44 https://austingroupbugs.net/view.php?id=1801#c6702 ---------------------------------------------------------------------- w.r.t. Note: 0006686 > 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. My test was indeed wrong - I got confused about how pipes work, sorry for that. Using your corrected test gives these results: ``` a b xargs: sh: exited with status 255; aborting Read 1 ``` on every single implementation I could test (GNU findutils, FreeBSD, OpenBSD, NetBSD, Illumos, Busybox, Toybox, DragonFlyBSD, MidnightBSD, GhostBSD), except for slight differences as to the wording of the error message between the implementations. This makes sense to me as all implementations whose code I've checked use buffered I/O and do not ensure they only read a single item from the input before processing or anyhting like that, and their buffer is evidently large enough to contain the entire string `"a\nb\bc\nd"` and thus read it in its entirety before starting any invocation, as the tests above evidence (since the script's `read` fails due to immediately getting EOF because the whole pipe was already read by `xargs`) I also agree with your later conclusion that the behavior on all the existing implementations is also likely conforming - as opposed to a reading of a strict mandate they don't read any more input than necessary. > 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. I agree that it is important to have a clear standard with precise wording that doesn't lead to ambiguities, even for "nitpicky" objections. If you're wondering why I'm going through every xargs implementation I can find whenever you talk about an ambiguity in the standard, it's not to try to "refute" what you're pointing out or anything like it, it's largely simply to try and evaluate how easy figuring out what we want the standard to contain is: if all implementations do the same thing that's probably what the standard should mandate, whereas if implementations wildly diverge in behavior we probably want to think a little bit more about it and the objection might not be anywhere as "nitpicky" as one might have thought it to be. Finally, w.r.t. Note 0006699, I agree with the changes - they don't seem to mandate much of anything that could realistically change behavior in existing implementations that programs might have been relying on, the requirements seem pretty sensible, and the wording seems pretty clear to me. 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 2024-02-26 10:17 geoffclare Status Resolved => Under Review 2024-02-26 10:17 geoffclare Resolution Accepted As Marked => Reopened 2024-03-01 11:40 geoffclare Note Added: 0006699 2024-03-01 11:42 geoffclare Note Edited: 0006699 2024-03-03 18:44 gabravier Note Added: 0006702 ======================================================================
