Re: [OCLUG-Tech] is "xargs" really still useful just for limiting command line size?

All I know is that I have hit the arg list too long error. That was redhat-6.x so maybe it was old. I think it is worth mentioning the solution if they ever run into that problem. On March 16, 2018 11:04:37 AM "Robert P. J. Day" wrote: On Fri, 16 Mar 2018, James

Re: [OCLUG-Tech] is "xargs" really still useful just for limiting command line size?

On Fri, 16 Mar 2018, J C Nash wrote: This may introduce a tangent, but I find the limit is often not the coded one but issues related to - getting 250 characters into the line and not remembering whether the parameter should be X or x and what the difference is. Indeed. For those who may

Re: [OCLUG-Tech] is "xargs" really still useful just for limiting command line size?

On Fri, 16 Mar 2018 11:04:30 -0400 (EDT) "Robert P. J. Day" wrote: > i'm fairly sure i can conclude that a command can be at least 3882671 > characters long, can i not? It depends on the shell, I'd think. Regards, Dianne. ___

Re: [OCLUG-Tech] is "xargs" really still useful just for limiting command line size?

On Fri, 16 Mar 2018, Michael P. Soulier wrote: > On 16/03/18 Robert P. J. Day said: > > > again, as i mentioned, i do understand the value of xargs > > because of the plethora of useful "tricks" like the above, but > > those features aside, the basic question is still, does xargs > > still have

Re: [OCLUG-Tech] is "xargs" really still useful just for limiting command line size?

> On Fri, 16 Mar 2018, James wrote: > > It is necessary for running a command on all files matching a > > pattern. > On Fri, Mar 16, 2018 at 11:04:30AM -0400, Robert P. J. Day wrote: > i'm pretty sure that's not true. > > […] > > $ echo /* | wc -c > 119 > $ echo /*/* | wc -c > 159988 >

Re: [OCLUG-Tech] is "xargs" really still useful just for limiting command line size?

On 16/03/18 Robert P. J. Day said: > again, as i mentioned, i do understand the value of xargs because of > the plethora of useful "tricks" like the above, but those features > aside, the basic question is still, does xargs still have value > *solely* for its ability to run commands in

Re: [OCLUG-Tech] is "xargs" really still useful just for limiting command line size?

On Fri, 16 Mar 2018, James wrote: > It is necessary for running a command on all files matching a > pattern. i'm pretty sure that's not true. > Wildcarding substitutes the full file names of each matching result > of the wildcard on the command line. Thousands of matching > names/paths can

Re: [OCLUG-Tech] Consistency (was Re: is "xargs" really still useful just for limiting command line size?)

On Fri, 16 Mar 2018 10:31:33 -0400 Dianne Skoll wrote: > On Fri, 16 Mar 2018 10:26:36 -0400 > Shawn H Corey wrote: > > > git ls-files -z | xargs -0 grep 'function_name' > > > The -z separates the names with a ASCII NUL and the -0 (minus zero) >

Re: [OCLUG-Tech] is "xargs" really still useful just for limiting command line size?

It is necessary for running a command on all files matching a pattern. Wildcarding substitutes the full file names of each matching result of the wildcard on the command line. Thousands of matching names/paths can easily blow up the buffer. I think it works that way. :-) On March 16, 2018

Re: [OCLUG-Tech] is "xargs" really still useful just for limiting command line size?

On Fri, 16 Mar 2018, Shawn H Corey wrote: > On Fri, 16 Mar 2018 09:59:53 -0400 > "Michael P. Soulier" wrote: > > > On 16/03/18 Robert P. J. Day said: > > > > > course i taught recently had a section on "xargs", emphasizing > > > its value(?) in being able to run a

[OCLUG-Tech] Consistency (was Re: is "xargs" really still useful just for limiting command line size?)

On Fri, 16 Mar 2018 10:26:36 -0400 Shawn H Corey wrote: > git ls-files -z | xargs -0 grep 'function_name' > The -z separates the names with a ASCII NUL and the -0 (minus zero) > allows xarg to read them correctly. This is useful if the files have > spaces in their names.

Re: [OCLUG-Tech] is "xargs" really still useful just for limiting command line size?

On 2018-03-16 10:26 AM, Shawn H Corey wrote: git ls-files -z | xargs -0 grep 'function_name' The -z separates the names with a ASCII NUL and the -0 (minus zero) allows xarg to read them correctly. This is useful if the files have spaces in their names. Such files are not permitted to exist in

Re: [OCLUG-Tech] is "xargs" really still useful just for limiting command line size?

On Fri, 16 Mar 2018 09:59:53 -0400 "Michael P. Soulier" wrote: > On 16/03/18 Robert P. J. Day said: > > > course i taught recently had a section on "xargs", emphasizing its > > value(?) in being able to run a command in bite-size pieces but, > > these days, is that

Re: [OCLUG-Tech] is "xargs" really still useful just for limiting command line size?

On Fri, Mar 16, 2018 at 09:27:21AM -0400, Robert P. J. Day wrote: > course i taught recently had a section on "xargs", emphasizing its > value(?) in being able to run a command in bite-size pieces but, these > days, is that really that much of an issue? If it was a year ago when I tried to glob

Re: [OCLUG-Tech] is "xargs" really still useful just for limiting command line size?

On Fri, 16 Mar 2018 09:27:21 -0400 (EDT) "Robert P. J. Day" wrote: > course i taught recently had a section on "xargs", emphasizing its > value(?) in being able to run a command in bite-size pieces but, these > days, is that really that much of an issue? Yes. > $

Re: [OCLUG-Tech] is "xargs" really still useful just for limiting command line size?

On 16/03/18 Robert P. J. Day said: > course i taught recently had a section on "xargs", emphasizing its > value(?) in being able to run a command in bite-size pieces but, these > days, is that really that much of an issue? My main use for it. git ls-files | xargs grep 'function_name'

Re: [OCLUG-Tech] is "xargs" really still useful just for limiting command line size?

This may introduce a tangent, but I find the limit is often not the coded one but issues related to - long lines wrapping round and becoming difficult to read - inevitable fumble fingers - getting 250 characters into the line and not remembering whether the parameter should be X or x and