next »

[vsloathe]

Well you have to understand first that BASH is magic and can tell what you're trying to do.

Not really, but pipes are definitely voodoo magic.

xargs is just a way of including whatever you get on stdout as an argument. It will put it in the proper place when it needs to, there is a way of specifying what xargs should put where but by that point, you should just write BASH script and use proper variables.

a pipe is equivalent to a less than/greater than, except instead of writing to a file you're writing to the stdin of the right side of the pipe (which is a file anyway) from the stdout of the left side (which is also a file but we may as well think of the std's as streams not files [even though there's technically no difference! /unixnerd]).

In this example:

Code:

find . -name *.php | xargs grep '$varName'

xargs will automatically give grep the name of each file as the last argument. No need to do a loop or anything, it knows that a newline terminates a shell command. Alternatively, it's more straightforward to do this:

Code:

grep -r '$varName' *.php

but it's much less flexible.

[perkiset]

Excellent stuff, VS, thanks much.

OK, some QQs:
* How does xargs know what param and where? Is there some voodoo that tar exposes so (things like) xargs will know what to deliver?
* I assume from your example that the regex is going to be quicker than the -not-name ... why is that? You seem (in other threads) to be wary of turning on the regex engine because of the overhead?
* I'm not sure I understand the difference between using < and | ... if I read you correctly, they both push stdin towards the receiving app.
* In fact, I'm pretty sure I don't understand the difference and/or usage between < > and | entirely. 

[vsloathe]

Sorry, I've been busy lately >_<

* How does xargs know what param and where? Is there some voodoo that tar exposes so (things like) xargs will know what to deliver?

Piping to xargs says "xargs, take the output of the previous command, and give it to the end of this command". By default, it's the predicate (end) of the command.

* I assume from your example that the regex is going to be quicker than the -not-name ... why is that? You seem (in other threads) to be wary of turning on the regex engine because of the overhead?

No, I rail against turning on the PCRE when it's not necessary. This kind of regex parsing is compiled right into the kernel, you can't get much faster. Now, if you used egrep or grep -P, then we should start to talk about performance impact because that spools up the PCRE.

* I'm not sure I understand the difference between using < and | ... if I read you correctly, they both push stdin towards the receiving app.

Not quite. Technically, pipes are for streams and < and > (and >> and <<) are for files, but as we both know there is only a technical distinction between a file and a stream in UNIX.
So, if we have 2 pieces of a command,  commandSubA and commandSubB:

Code:

commandSubA < commandSubB = execute (or read, as it's usually a file) commandSubB and write its output to commandSubA

Code:

commandSubA > commandSubB = inverse of above. execute (or read from) commandSubA and write the output to commandSubB

Code:

commandSubA | commandSubB = pipe the stdout of commandSubA *directly* to the stdin of commandSubB

the important distinction between using greater than/less than vs. pipe is that a pipe is meant to handle a stream, and the greater than/less than is meant to handle a file. using >> or << will append instead of overwriting. I log the output of a lot of my cron jobs using >>

* In fact, I'm pretty sure I don't understand the difference and/or usage between < > and | entirely. 

Hopefully I asplained it well enough above.

Everyone has different styles of learning, but I learned all that just by trying different things until one worked. I never read the instructions until it's way too late lol

[perkiset]

That's great stuff VS, thanks man.

The regex argument makes a lot of sense now ... and bends me towards using it more in my shell scripting. I did not understand the difference.

@xargs - that's damn handy, going to give that a bunch of think. Although I can't see any benefit in using it instead of pre-written shell scripts for configuration (my configure.perk files for building Apache, PHP etc) ... are you saying I could create a file of all the switches I wanted and then xargs the file into configure?

Great expl. on pipes v.s streams, makes a lot of sense although I'll need to put that into usage to grok and seal the memory. Thanks man.

[vsloathe]

are you saying I could create a file of all the switches I wanted and then xargs the file into configure?

something like:

Code:

cat mySwitches.txt | xargs ./config

just make sure mySwitches.txt doesn't have line breaks, or it's going to execute ./config [line #] for each line in the file.

I think that's what you're asking, right? You can definitely do that, it's the type of thing xargs was made for.

[perkiset]

yes exactly... that's a silly example because I like to see my configure.perk script all wrapped up neat and tidy, but thanks for the expl.

When you say, no line breaks or it will execute the command for each line, then why doesn't tar czvf with xargs continually overwrite the tarball I'm trying to create?

[vsloathe]

Because pipe keeps the stdin of your [command that is being piped TO] open.

Actually, now that I think about it I was probably just on crack this morning when I said you can't have line breaks. hmmmm

My brain is addled today, quit  before 9am.

 

[perkiset]

OK gotcha, thanks again.