Talk:xargs

This article was nominated for deletion on 18 February 2012 (UTC). The result of the discussion was keep.

~~Some too often "often" should be killed from the first paragraphs, but not me. --ReiniUrban 17:02, 12 October 2007 (UTC)~~ Done.[reply]

sublists large enough to be acceptable -> "small enough"?? —Preceding unsigned comment added by 209.213.198.25 (talk) 20:51, 23 October 2007 (UTC)[reply]

The word backquote and backtick are both used but they are the same. This is confusing 62.243.90.41 (talk) 04:07, 28 January 2008 (UTC)[reply]

No mention is made of xargs having a logical EOF string, by default "_". This causes problems if a file exists called "_". Very recently it appears as if GNU xargs may have stopped logical EOF processing by default, but for years it's been on. — Ralph Corderoy (talk) 11:03, 20 June 2008 (UTC)[reply]

Missing the point

I have a strong suspicion that this article misses the point of xargs. Xargs really is a map/apply function that takes a stream of values, maps it to a vector or a sequence of vectors, and then applies these vectors to the specified command. It can be parameterized to change the nature of the mappings, and this is certainly a necessary side effect, but I don't think that these are really the main feature of xargs, despite them being a bit more obvious. Evan Cofsky, Musician, Computer Scientist (talk) 02:19, 23 July 2010 (UTC)[reply]

Possible Problem

I understand it to be bad in form to use RM in examples as it deletes files. A command line newbie will be tempted to cut and paste, leading to problems. —Preceding unsigned comment added by 69.254.160.214 (talk) 06:31, 22 March 2011 (UTC)[reply]

Advert for GNU Parallel

There's a big plug for GNU Parallel with the text cut-and-pasted from the man page. After complaining that xargs isn't line-orientated it suggests Parallel will cure all of that whereas it would have similar problems if, e.g., the filenames contained linefeed. xargs' -0 option is the consistent solution to this, the advert for Parallel seems unwarranted. -- Ralph Corderoy (talk) 12:34, 11 October 2010 (UTC)[reply]

This reflects a design defect in xargs. There is no reason that xargs cannot have an option to split on newlines. The posix spec says that this is not the default behavior, but the designed default behavior does not prevent this option from being included in newer versions. And since newlines-without-other-whitespace are a valid delimiter in almost all other contexts in the environments where xargs is available (including shell scripts - for example, consider `<file while read line; do echo "'$line"; done`), the absence of this option is a glaring defect in the design of xargs. So it's appropriate to advertise any available alternatives which do not have this defect. 159.54.131.7 (talk) 15:00, 14 June 2012 (UTC)[reply]

Actually xargs does have an option to split on newlines. The option is -d. But using the option -0 is still safer, since Unix path names are not, properly speaking, text. — Preceding unsigned comment added by JamesYoungman (talk • contribs) 18:24, 1 June 2014 (UTC)[reply]

A simple workaround

It is is very simple to overcome the problem with commands that can't output null characters. As an example :

 find | tr \\n \\0 | xargs -0 grep 'findme'

Is equivalent to

 find -print0 | xargs -0 grep 'findme'

A simple function can be written to encapsulate this :

 # sample xargs -0 encapsulation function in bash
 function xargs0 () { tr \\n \\0 | xargs -0 "$@"; }

It is therefore unnecessary to use third-party tools such as "Parallel". —Preceding unsigned comment added by 83.113.221.163 (talk) 21:39, 2 March 2011 (UTC)[reply]

Also, xargs has an option to specify the delimiter, so that first example is equivalent to

 find | xargs -d \\n grep 'findme'

93.6.208.97 (talk) 08:11, 22 April 2011 (UTC)[reply]

I've modified the "separator problem" to show the correct fix using find -print0 and then indicate tr as an alternative. It seems more helpful to point out the easy way to fix the issue first. The tr "solution" should merely be a way to understand the issue, not fix it. ralfoide (talk) 21:30, 16 June 2011 (UTC)[reply]

You have a good point here, but for some versions of xargs the -d option is not available (like the version 4.1.20 I was using when I developped the xargs0 function), therefore the "tr" trick is worth mentionning also for that. 192.54.144.229 (talk) 10:25, 9 February 2012 (UTC)[reply]

Better mv solution

I realise that the objective here is to demonstrate the use of xargs rather than mv, however, I personally think it is always worthwhile to show best-practices.

In my experience, the mv command is most robust when utilised with find/xargs when specifying target-directory[1] as in the following example:

find . | xargs mv --target-directory=foobar

Groovyspaceman (talk) 19:39, 20 February 2012 (UTC)[reply]

Does the argument always end up at the end of the command line given after "xargs"?

First of all, the article generally explains quite poorly what xargs really does. It just says in what type of situations it can be useful and that xargs breaks the argument list up into sublists small enough to be acceptable, but it doesn't say what xargs does with the sublists. Then it just gives some example where xargs is used and tells what it does in those specific cases.

Anyway, is it possible to construct command lines where the arguments inserted by xargs are not inserted at the end of the command line, but at an arbitrary possition (for example second last of the arguments on the command line that is created)? Can the arguments inserted by xargs be inserted more than once (in the same command line)? Also, can you append or prepend some text to the arguments inserted by xargs? —Kri (talk) 14:16, 4 April 2013 (UTC)[reply]

a) This isn't StackOverflow. b) Yes. Read the manpage for option -I. Traditionally it's used with -I{}. 66.119.84.21 (talk) 16:47, 17 June 2013 (UTC)[reply]

A whole wikipedia page for this?

I read the information in this page after following a link to it, and did appreciate what I read. However, I'm really surprised to read all these details on Wikipedia. Shouldn't all this be in the man pages and/or readme files for xargs and parallel? Do we really need to drown Wikipedia in such minute details? My understanding is that Wikipedia is meant to be an Encyclopedia, which (by it's own definition) should be "a reference work or compendium providing summaries of knowledge ...". Indeed, I would expect summaries. Not gory usage details of some obscure Unix command (obscure for over 99% of people, most of whom don't even know what "Unix" is).

I feel that the first sentence ("xargs is a command on Unix and most Unix-like operating systems used to build and execute commands from standard input. It converts input from standard input into arguments to a command.") is enough. All the rest of this article, even though useful, doesn't belong in Wikipedia. Albert25 (talk) 23:25, 1 January 2019 (UTC)[reply]