[PATCH] Add new xargs -N (--newline) option for newline-terminated input

Sorry, I didn't think to add [PATCH] to the subject line... Deven On Sun, Mar 2, 2025 at 5:05 AM Deven T. Corzine wrote: > The attached patch adds a new "-N" (or "--newline") option to xargs. This > is simply an alias for "-d'\n'" for conveni

Add new xargs -N (--newline) option for newline-terminated input

The attached patch adds a new "-N" (or "--newline") option to xargs. This is simply an alias for "-d'\n'" for convenience, since newline-terminated lists of filenames are very common, not just from "find -print" but also from many other tools t

[bug #66591] default command of xargs in texinfo documentation

Follow-up Comment #2, bug #66591 (group findutils): P.S. The usage output from 'xargs --help' had it wrong; I fixed it (and also added a sentence about the default COMMAND): -Usage: xargs [OPTION]... COMMAND [INITIAL-ARGS]... +Usage: xargs/xargs [OPTION]... [COMMAND [INITIAL-ARGS]...]

[PATCH] xargs: clarify command as optional in --help output

* xargs/xargs.c (usage): Fix synopsis by wrapping COMMAND in '[...]', because it is in fact optional. Also add a sentence that the default COMMAND is 'echo'. --- xargs/xargs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xargs/xargs.c b/xargs/xa

[bug #66591] default command of xargs in texinfo documentation

Update of bug #66591 (group findutils): Category: xargs => documentation Status:None => Fixed Assigned to:None => berny Fixed Release:None

[PATCH 3/5] xargs: simplify error handling for gnulib's safe_read function

The gnulib/NEWS file states: SAFE_READ_ERROR and SAFE_WRITE_ERROR are now obsolescent; callers can just check for < 0. * xargs/xargs.c (xargs_do_exec): Adjust error handling of safe_read accordingly. --- xargs/xargs.c | 110 +- 1 file chan

[bug #66591] default command of xargs in texinfo documentation

URL: <https://savannah.gnu.org/bugs/?66591> Summary: default command of xargs in texinfo documentation Group: findutils Submitter: toomas Submitted: Sat 21 Dec 2024 02:16:38 PM UTC Category:

Re: xargs: doesn't fail on missing terminator (which may have severe consequences)

ate" which means it is something in between > > > 2 entries: > > >     entry1  entry2 > > > It is and was never a "terminator", i.e., something acknowledging > > > that the previous > > > entry is committed. > > >    entry1 > &

Re: xargs: doesn't fail on missing terminator (which may have severe consequences)

something acknowledging > > that the previous > > entry is committed. > >    entry1 That might be what the "usage output" says, but it is not what find(1) does. It is treating NUL as a terminator in the sense that the last byte output with -print0 is a NUL. But that

Re: xargs: doesn't fail on missing terminator (which may have severe consequences)

On 12/15/24 20:47, Bernhard Voelker wrote: `xargs -0` is similar to many tools allowing Zero-delimited input. And often the last entry of input does not have to be Zero-terminated. Here some examples from the GNU coreutils. * `sort -z`: * `uniq -z`: * `cut -z` * `tail -z`: P.S. I forgot to

Re: xargs: doesn't fail on missing terminator (which may have severe consequences)

wait for it happening in the wild. Again, consider the find ... | xargs rm -rf example, in which a "line" is truncated to an incomplete "/". I'm interested in a real-life example, because a theoretical danger is ... theoretical. WRT `rm -rf /` - this has become a famous o

Re: xargs: doesn't fail on missing terminator (which may have severe consequences)

ind ... | xargs rm -rf example, in which a "line" is truncated to an incomplete "/". > Usually a data producer is buffered, and therefore atomically > outputting entries in a consistent way. It may were well be not buffered, for example when someone uses stdbuf with mo

Re: xargs: doesn't fail on missing terminator (which may have severe consequences)

Hi Christoph, On 12/12/24 4:17 PM, Christoph Anton Mitterer wrote: So I'd still ask you to consider whether GNU's xargs can be modified accordingly (and not just in some POSIXLY_CORRECT mode), as any other behaviour seems truly dangerous to me. I never saw a practical example why i

Re: xargs: doesn't fail on missing terminator (which may have severe consequences)

rd requires input to be a text file (which means all lines must be newline terminated). So I'd still ask you to consider whether GNU's xargs can be modified accordingly (and not just in some POSIXLY_CORRECT mode), as any other behaviour seems truly dangerous to me. Cheers, Chris.

Re: xargs: doesn't fail on missing terminator (which may have severe consequences)

On Mon, 2024-12-09 at 21:00 +0100, Bernhard Voelker wrote: > The above test case can be simplified to the cases: > >    $ printf 'hello' | xargs -0 printf "<%s>\n" >    > >    $ printf 'hello\0' | xargs -0 printf "<%s>\n

Re: xargs: doesn't fail on missing terminator (which may have severe consequences)

On 12/9/24 03:34, Christoph Anton Mitterer wrote: Hey. Not sure whether this has been brought up before (at least a quick search didn't reveal anything in the bug tracker or the archive). xargs -0 still executes the command even when no terminating NUL has been found in the (last) line

xargs: doesn't fail on missing terminator (which may have severe consequences)

Hey. Not sure whether this has been brought up before (at least a quick search didn't reveal anything in the bug tracker or the archive). xargs -0 still executes the command even when no terminating NUL has been found in the (last) line. As shown by e.g. the following script foo.sh: #

Re: Re: xargs mock run

On Wed, Oct 09, 2024 at 11:49:20AM +0200, oset wrote: > raf wrote: > ... | xargs echo cmd ... Good hack. Thing is, I tried > it before and it did not work. That is why I strayed the whole topic. > Now it works, so thats OK. There is a problem though: $  echo a > > a.txt; echo

Re: Re: xargs mock run

raf wrote: > ... | xargs echo cmd ... Good hack. Thing is, I tried it before and it did not work. That is why I strayed the whole topic. Now it works, so thats OK. There is a problem though: $  echo a > a.txt; echo b > b.txt; echo c > "c with spaces.txt" $  ech

Re: Re: Re: xargs mock run

raf wrote: can't easily read your response because of the formatting and html character encoding I dont know why it happened, apologize. I guess due to pasteing from clipboard. If I write it 'manually' in client it will likely not happen. I think what you are trying to achieve might loo

Re: Re: xargs mock run

t; You can. Just replace the actual > command with "sh -c 'echo ACTUAL_COMMAND'". I > cannot. That is not the same. I dont know what it does, but not what > I wanted, not what I was talking about. ~~~ $ echo a > a.txt; echo > bb > b.txt $ sh -c 'echo * | xarg

Re: Re: xargs mock run

cho ACTUAL_COMMAND'". I cannot. That is not the same. I dont know what it does, but not what I wanted, not what I was talking about. ~~~ $ echo a > a.txt; echo bb > b.txt $ sh -c 'echo * | xargs gzip -k' ~~~ There is nothing here. What I expected to see/get was:

Re: xargs mock run

On Mon, Oct 07, 2024 at 07:27:24PM +0200, oset wrote: > Often, when user uses bit more complex syntax with xargs (or find -exec, for > that matter) the command spectacularly fails, and they dont know why. It > would be beneficial to be able to mock run a command - just print what is

xargs mock run

Often, when user uses bit more complex syntax with xargs (or find -exec, for that matter) the command spectacularly fails, and they dont know why. It would be beneficial to be able to mock run a command - just print what is to be run, so user knows what exactly is passed to the program, so

[bug #65998] xargs strange behavior

Follow-up Comment #3, bug #65998 (group findutils): Further hint: one can see what's going on with the '-t,--verbose' option: $ echo '-e test1 -e test2' | xargs -t echo -e test1 -e test2 test1 -e test2 _

[bug #65998] xargs strange behavior

Update of bug #65998 (group findutils): Status:None => Working as Intended Assigned to:None => jay Open/Closed:Open => Closed __

[bug #65998] xargs strange behavior

Follow-up Comment #1, bug #65998 (group findutils): Hello, xargs is executing "echo" (since no command was given), which swallows/uses the -e an -n options. If you replace "xargs" with "xargs printf '%s\n' in your examples you will see that xargs passes e

[bug #65998] xargs strange behavior

URL: <https://savannah.gnu.org/bugs/?65998> Summary: xargs strange behavior Group: findutils Submitter: None Submitted: Wed 17 Jul 2024 12:34:25 PM UTC Category: xargs Severity: 3 -

[bug #65890] xargs keeps child processes in zombie state before starting a new process

/findutils.git/tree/xargs/xargs.c I do not see how it could not also happen in the latest changes as it still has: /* Make sure to listen for the kids. */ signal (SIGCHLD, SIG_DFL); The fix probably should be to install a signal handler for SIGCHLD and call waitpid in the signal handler

[bug #65890] xargs keeps child processes in zombie state before starting a new process

Follow-up Comment #1, bug #65890 (group findutils): You didn't state what version of findutils this problem affects. Is this problem reproducible with findutils version 4.10.0? ___ Reply to this item at:

[bug #65890] xargs keeps child processes in zombie state before starting a new process

URL: <https://savannah.gnu.org/bugs/?65890> Summary: xargs keeps child processes in zombie state before starting a new process Group: findutils Submitter: pcpa Submitted: Tue 18 Jun 2024 05:18:32 PM -03 Ca

[bug #64480] Docs: Replace examples containing deprecated xargs option "-l" with "-L 1"

Update of bug #64480 (group findutils): Fixed Release:None => 4.10.0 ___ Reply to this item at: ___ Mess

[bug #63934] tests/xargs/verbose-quote.sh fails with dash shell as /bin/sh

Update of bug #63934 (group findutils): Open/Closed:Open => Closed Fixed Release:None => 4.10.0 ___ Reply to this item at:

[bug #62325] is This Typo?(xargs.1)

Update of bug #62325 (group findutils): Open/Closed:Open => Closed Fixed Release:None => 4.10.0 ___ Reply to this item at:

[bug #65794] Automake warnings for tests/xargs/test-sigusr.c

Update of bug #65794 (group findutils): Open/Closed:Open => Closed Fixed Release:None => 4.10.0 ___ Reply to this item at:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Update of bug #64442 (group findutils): Open/Closed:Open => Closed Fixed Release:None => 4.10.0 ___ Reply to this item at:

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

Update of bug #64451 (group findutils): Open/Closed:Open => Closed Fixed Release:None => 4.10.0 ___ Reply to this item at:

[bug #65794] Automake warnings for tests/xargs/test-sigusr.c

Update of bug #65794 (group findutils): Status:None => Fixed ___ Follow-up Comment #1: This problem is fixed in the git code for findutils. To resolve your problem, you could either w

[bug #58156] Order of xargs -L and -I flags matters

Update of bug #58156 (group findutils): Open/Closed:Open => Closed ___ Reply to this item at: ___ Mess

[bug #37093] /usr/bin/xargs: rm: Argument list too long during make distclean in cross chroot

Update of bug #37093 (group findutils): Status: Need Info => Obsolete Assigned to:None => jay Open/Closed:Open => Closed __

[bug #65794] Automake warnings for tests/xargs/test-sigusr.c

URL: <https://savannah.gnu.org/bugs/?65794> Summary: Automake warnings for tests/xargs/test-sigusr.c Group: findutils Submitter: jay Submitted: Sun 26 May 2024 11:24:33 AM UTC Category

[bug #64741] Graceful stop of xargs

Update of bug #64741 (group findutils): Severity: 3 - Normal => 2 - Minor ___ Reply to this item at: ___ Mess

[bug #55190] xargs documentation is confusing about the usage of -i and -I (capital i), and doesn't have any examples on this options

Update of bug #55190 (group findutils): Category: xargs => documentation Severity: 3 - Normal => 2 - Minor ___ Follow-up Comment #4: Bernhard

[bug #42937] xargs --show-limits environment size subtracted twice possibly

Update of bug #42937 (group findutils): Severity: 3 - Normal => 4 - Important ___ Follow-up Comment #3: Do you have an update? ___ Reply to t

[bug #38658] If the command exec() fails, xargs terminates prematurely

Update of bug #38658 (group findutils): Status:None => Working as Intended Assigned to:None => jay Open/Closed:Open => Closed _

[bug #20891] exit status enhancement for xargs

Update of bug #20891 (group findutils): Status:None => Wont Fix Assigned to:None => jay Open/Closed:Open => Closed __

[bug #20891] exit status enhancement for xargs

Follow-up Comment #4, bug #20891 (group findutils): If the current behaviour complies with POSIX, I don't think there is a bug to fix here. Probably, any convenience gained by changing this is obviated by the incompatibility caused by the change.

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

067) ___ Additional Item Attachment: File name: 0001-xargs-restart-stdin-reads-interruipted-by-SIGUSR1-SI.patch Size: 2KiB <https://file.savannah.gnu.org/file/0001-xargs-restart-stdin-reads-interruipted-by-SIGUSR1-SI.patch?file_id=56067> AGPL NOTICE These attachments are

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Additional Item Attachment, bug #64442 (group findutils): File name: 0002-doc-Mention-the-changes-to-xargs-P.patch Size: 3KiB <https://file.savannah.gnu.org/file/0002-doc-Mention-the-changes-to-xargs-P.patch?file_id=56066> AGPL NOTICE These attachments are served by Savane. Y

Re: [bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

001 From: James Youngman Date: Sun, 19 May 2024 11:27:46 +0100 Subject: [PATCH 2/2] [doc] Mention the changes to xargs -P To: findutils-patc...@gnu.org * doc/find.texi: explain how xargs -P affects the handling of the SIGUSR1 and SIGUSR2 signals. * xargs/xargs.1: Likewise. --- doc

Re: [bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

This patch addresses the POSIX compliance aspect explained by Geoff Clare. A test is included. From b560e3f911c1eb0095a2c07a461bc28f7335fbd1 Mon Sep 17 00:00:00 2001 From: James Youngman Date: Sun, 19 May 2024 11:05:38 +0100 Subject: [PATCH] [xargs] POSIX requires SIGUSR1/2 to be fatal if not

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #12, bug #64442 (group findutils): I attach patch which deals with the POSIX compliance aspect explained by Geoff. (file #56065) ___ Additional Item Attachment: File name: 0001-xargs-POSIX-requires-SIGUSR1-2-to-be

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Update of bug #64442 (group findutils): Assigned to:None => jay ___ Reply to this item at: ___ Mess

Re: [bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

Fixed in git with the attached patch. On Thu, Jul 20, 2023 at 8:46 AM anonymous wrote: > URL: > <https://savannah.gnu.org/bugs/?64451> > > Summary: Unexpected behaviour of xargs when multiple > children > exit with 255 in parallel >

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

Update of bug #64451 (group findutils): Status:None => Fixed Assigned to:None => jay ___ Follow-up Comment #6: This problem is fix

[PATCH 1/2] xargs.1: narrow down deprecation on the -i option

The long option --replace it not deprecated, only the short form. * xargs/xargs.1: Clarify the above better by explicitly mentioning the short -i form. --- xargs/xargs.1 | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/xargs/xargs.1 b/xargs/xargs.1 index 23faec92..ef1f08f0

[bug #64741] Graceful stop of xargs

URL: <https://savannah.gnu.org/bugs/?64741> Summary: Graceful stop of xargs Group: findutils Submitter: None Submitted: Tue 03 Oct 2023 04:36:19 PM UTC Category: xargs Severity: 3 -

[bug #64480] Docs: Replace examples containing deprecated xargs option "-l" with "-L 1"

t; Closed ___ Follow-up Comment #1: Good idea, thanks - pushed at: https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=ad4e2bdde0 Likewise, I changed an `xargs -i` example to use --replace: https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=3a

Re: [PATCH] xargs.1: some remarks and editing fixes in the man page

On 6/29/23 00:13, Bernhard Voelker wrote: Hello Bjarni, On 6/20/23 20:13, Bjarni Ingi Gislason wrote: > [...] many thanks for the fixes - this is highly appreciated. I like them all. Pushed at: https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=a77c161b651c6157a91f26873c63e0cd8392e4

[bug #64480] Docs: Replace examples containing deprecated xargs option "-l" with "-L 1"

URL: <https://savannah.gnu.org/bugs/?64480> Summary: Docs: Replace examples containing deprecated xargs option "-l" with "-L 1" Group: findutils Submitter: sebastiancarlos Submitted: Thu 2

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

Follow-up Comment #5, bug #64451 (project findutils): >From wait(2): *WIFSTOPPED(*_wstatus_*)* returns true if the child process was stopped by delivery of a signal; this is possible only if the call was done using *WUNTRACED* or when the child is being traced (see *ptrace*(2)). OK so I g

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

Follow-up Comment #4, bug #64451 (project findutils): I still can't figure out how catching SIGSTOP is supposed to work. Neither SIGSTOP nor SIGTSTP seem to be caught. ___ Reply to this item at: _

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

Follow-up Comment #3, bug #64451 (project findutils): I've been able to fix this behaviour by explicitly calling _wait_for_proc_all_(). I can't imagine any reprocussions from doing this, but the current code expects _wait_for_proc_all_() to be called _atexit_() so I would need some insight into wh

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

Follow-up Comment #2, bug #64451 (project findutils): Because checks for WSTOPSIG and WTERMSIG are done in the same place, sending SIGTERM or SIGSTOP to the children should also cause the same behaviour. In reality though trying to _kill_ chuldren with this tester seq 3 | xargs -n1 -P0 sh -c

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

Follow-up Comment #1, bug #64451 (project findutils): A workaround for scripts is to perform checks as soon as possible and exit 1 (or other value) instead. Potentially hundreds of processes will still be spawned but this avoids potentially processing outputs that are not yet complete. Ano

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

URL: <https://savannah.gnu.org/bugs/?64451> Summary: Unexpected behaviour of xargs when multiple children exit with 255 in parallel Group: findutils Submitter: None Submitted: Thu 20 Jul 2023 07:46:06

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #11, bug #64442 (project findutils): It is probably more reasonable to test with USR2 as pkill will signal any xargs running on the system. ___ Reply to this item at: <https://savannah.gnu.org/bugs/?64

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #10, bug #64442 (project findutils): An automated test for this issue can be done with sleep 0.2 && pkill -USR1 xargs & { sleep 0.5 && echo success; } | xargs ___ Reply to this item at: <h

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #9, bug #64442 (project findutils): I decided to strace xargs on my phone and curiously read() is interrupted there as well but does not cause any problems. (file #54945) ___ Additional Item Attachment: File name

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #8, bug #64442 (project findutils): I retract my previous statement the patch works, I just accidentaly ran system xargs instead of the locally built one. ___ Reply to this item at: <https://savannah.gnu.org/b

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #7, bug #64442 (project findutils): After testing further I found that SA_RESTART only fixes the case of waiting on read. I managed to trigger _xargs: error closing file_ by running this c=1; while true; do printf '%s\n' "$c"; c=$((c+1)); done | xargs and s

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #6, bug #64442 (project findutils): Setting _sa_flags_ to SA_RESTART fixes this. (file #54944) ___ Additional Item Attachment: File name: sa_flags.diff Size:0 KB

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

an unspecified value that does not exceed the original timeout value. If the flag is not set, interruptible functions interrupted by this signal shall fail with _errno_ set to *[EINTR]*. ... xargs sets _sa_flags_ to 0 xargs.c:735 xargs.c:741 sigact.sa_flags = 0; so read() is interrupted. safe_r

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #4, bug #64442 (project findutils): Here is a diff between a normal xargs execution and one interrupted with SIGUSR1. Normal execution is just running xargs and entering ^D. --- strace-normal.txt 2023-07-19 14:31:18.639157032 +0300 +++ strace-usr1.txt 2023-07-19 14:21

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #3, bug #64442 (project findutils): I had a quick look at the code, and the signal handler for SIGUSR1/SIGUSR2 is always setup without regard to whether or not the -P option was used. I couldn't see why those signals would terminate xargs (but it did when I tested it on

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #2, bug #64442 (project findutils): When fixing this, please also consider changing xargs to make it conform to POSIX as regards signal handling. POSIX does not allow xargs to handle SIGUSR1 and SIGUSR2 differently from other signals. I.e. if they are inherited as ignored they

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #1, bug #64442 (project findutils): I got same behaviour after building from findutils-4.9.0.tar.xz and master branch commit 81bcf2b9b39a107a5417867edeb7d65c731a1720 ___ Reply to this item at:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

URL: <https://savannah.gnu.org/bugs/?64442> Summary: xargs closes stdin on receiving SIGUSR1 or SIGUSR2 Group: findutils Submitter: None Submitted: Tue 18 Jul 2023 02:52:32 PM UTC Category:

Re: [PATCH] xargs.1: some remarks and editing fixes in the man page

& have a nice day, BernyFrom 3b07c58a816d69cbced707df363f58e7cf7304f4 Mon Sep 17 00:00:00 2001 From: Bjarni Ingi Gislason Date: Tue, 20 Jun 2023 18:13:11 + Subject: [PATCH] xargs.1: some remarks and editing fixes in the man page Not in the patch. Output from "mandoc -T lint xarg

[PATCH] xargs.1: some remarks and editing fixes in the man page

Not in the patch. Output from "mandoc -T lint xargs.1": mandoc: xargs.1:1:2: WARNING: missing date, using "": TH ### Change '-' (\-) to '\(en' (en-dash) for a numeric range. GNU gnulib has recently (2023-06-18) updated its "build_aux/updat

[bug #63934] tests/xargs/verbose-quote.sh fails with dash shell as /bin/sh

Update of bug #63934 (project findutils): Status:None => Fixed Assigned to:None => berny ___ Follow-up Comment #1: Thanks for the re

Re: An interesting thing: about the naming of xargs

Applied, thanks.

Re: An interesting thing: about the naming of xargs

On 3/18/23 11:02, James Youngman wrote: Some minor improvements. I like it. Minor nit: > Subject: [PATCH] [doc] describe history of find, xargs and locate. ___^ git seems to swallow square brackets at the beginning of the "Subject:" line during `apply-

Re: An interesting thing: about the naming of xargs

versions of those programs. -@ref{History} for a history of @code{find}, @code{locate} and +See @ref{History} for a history of @code{find}, @code{locate} and @code{xargs}. The current maintainers of GNU findutils (and this manual) are Bernhard Voelker and James Youngman. Many other people have

Re: An interesting thing: about the naming of xargs

On Thu, Mar 16, 2023 at 6:12 PM James Youngman wrote: > > Interesting question. I just asked Herb Gellis, the inventor of > xargs. No answer yet. The answer turns out to be "eXecute command with ARGumentS". The first letter is "x" because there was no other comm

Re: An interesting thing: about the naming of xargs

On Thu, Mar 16, 2023 at 06:12:51PM +, James Youngman wrote: > Interesting question. I just asked Herb Gellis, the inventor of > xargs. No answer yet. "x" is often used in abbreviations and initialisms of words that start with "ex". it's quite possible

[bug #63934] tests/xargs/verbose-quote.sh fails with dash shell as /bin/sh

URL: <https://savannah.gnu.org/bugs/?63934> Summary: tests/xargs/verbose-quote.sh fails with dash shell as /bin/sh Group: findutils Submitter: thesamesam Submitted: Thu 16 Mar 2023 06:46:57 PM UTC Category

Re: An interesting thing: about the naming of xargs

Interesting question. I just asked Herb Gellis, the inventor of xargs. No answer yet.

Re: An interesting thing: about the naming of xargs

On 3/14/23 05:01, Nature wrote: Hi: Learned from Wikipedia : xargs (short for "extended arguments") is a command on Unix and most Unix-like operating systems. Why isn't it called exargs, but xargs. Would love to know what was considered at the time. It saves one

Re: An interesting thing: about the naming of xargs

> > On 14 Mar 2023, at 5:11 PM, Nature wrote: > > Hi: >Learned from Wikipedia : xargs (short for "extended arguments") is a > command on Unix and most Unix-like operating systems. > > Why isn't it called exargs, but xargs. Would love to

An interesting thing: about the naming of xargs

Hi: Learned from Wikipedia : xargs (short for "extended arguments") is a command on Unix and most Unix-like operating systems. Why isn't it called exargs, but xargs. Would love to know what was considered at the time.

[patch #10239] add two tests about find and xargs

Follow-up Comment #5, patch #10239 (project findutils): Thanks, pushed at https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=3c2d824ef5467c5b2adc711c175b74237b3cd018 with this fix for a typo found by `make syntax-check`: - rm -f out || framework_failure + rm -f out || framework_failure

[patch #10239] add two tests about find and xargs

Follow-up Comment #4, patch #10239 (project findutils): Sorry for the inconvenience caused to you. name: Shuiqing Zhou email: zhoushuiqing...@outlook.com ___ Reply to this item at: __

[patch #10239] add two tests about find and xargs

Follow-up Comment #3, patch #10239 (project findutils): Sorry regarding the question about the real name. Somehow I was expecting at least 2 parts like a first and a last name, but apparently this is not the case in all countries/languages. I discussed with the other maintainers, and we agreed th

[patch #10239] add two tests about find and xargs

Follow-up Comment #2, patch #10239 (project findutils): I am very sorry for the late reply. Yes, I'm willing to add Copyright assignment. And thank you very much for accepting this patch. My real name is zhoushuiqing, but it's a Chinese-style name. hahah...;-) ___

[patch #10239] add two tests about find and xargs

. the patch content: it needs some massage before applying. First of all, we want to have clean patches; 'git apply-mail' complains: $ git am ~/Downloads/0001-testcodes-about-find-and-xargs.patch Applying: tests: add tests about find -newer.. and xargs -d with escapechars Add two tests, o

[patch #10239] add two tests about find and xargs

URL: <https://savannah.gnu.org/patch/?10239> Summary: add two tests about find and xargs Project: findutils Submitter: zhoushuiqing Submitted: Thu 23 Jun 2022 07:38:56 AM UTC Category: None Pr

[bug #62621] xargs/find: buildcmd incorrectly sizes argv and envp

Follow-up Comment #1, bug #62621 (project findutils): Another thing: hypothetically, `xargs` could be built as a 32-bit binary, launching a 64-bit binary. In that case, `sizeof(void *)` is not enough, since `xargs` will think it's 4 while the kernel will think i

[bug #62621] xargs/find: buildcmd incorrectly sizes argv and envp

URL: <https://savannah.gnu.org/bugs/?62621> Summary: xargs/find: buildcmd incorrectly sizes argv and envp Project: findutils Submitter: freaky Submitted: Mon 13 Jun 2022 01:24:21 PM UTC Category:

[bug #62043] The xargs -r, --no-run-if-empty Option Is Ignored When a Delimiter Is Passed

Update of bug #62043 (project findutils): Status:None => Working as Intended Assigned to:None => berny Open/Closed:Open => Closed

  1   2   3   4   5   6   >