Mdthbs

The accepted answer has the right idea, but the key is to pass xargs the -n1 switch, which means "Execute the command once per line of output:"

cat file... | xargs -n1 command

Or, for a single input file you can avoid the pipe from cat entirely and just go with:

<file xargs -n1 command

In Bash or any other Bourne-style shell (ash, ksh, zsh, …):

while read -r line; do command "$line"; done

read -r reads a single line from standard input (read without -r interprets backslashes, you don't want that). Thus you can do either of the following:

$ command | while read -r line; do command "$line"; done  



$ while read -r line; do command "$line"; done <file

I agree with Keith, xargs is the most general tool for the job.

I usually use a 3 step approach.

• do the basic stuff until you have something you would like to work with


• prepare the line with awk so it gets the correct syntax


• then let xargs execute it, maybe with the help of bash.

There are smaller and faster ways, but this ways almost always works.

A simple example:

ls | 

grep xls | 

awk '{print "MyJavaProg --arg1 42 --arg2 "$1""}' | 

xargs -0 bash -c

the 2 first lines selects some files to work with,
then awk prepares a nice string with a command to execute and some arguments and $1 is the first column input from the pipe.
And finally I make sure that xargs sends this string to bash that just execute it.

It is a little bit overkill, but this recipe has helped me in a lot of places since it is very flexible.

GNU Parallel is made for that kind of tasks. The simplest usage is:

cat stuff | grep pattern | parallel java MyProg

Watch the intro video to learn more: http://www.youtube.com/watch?v=OpaiGYxkSuQ

Also, while read loop in fish shell (I assume you want fish shell, considering you used fish tag).

command | while read line

    command $line

end

Few points to note.

• 
  read doesn't take -r argument, and it doesn't interpret your backslashes, in order to make most common use case easy.


• You don't need to quote $line, as unlike bash, fish doesn't separate variables by spaces.


• 
  command by itself is a syntax error (to catch such use of placeholder arguments). Replace it with the real command.

If you need to control where exactly the input argument is inserted into your command line or if you need to repeat it several times then you need to use xargs -I{}.

Create an empty folder structure in another_folder that mirrors the subfolders in the current directory:

    ls -1d ./*/ | xargs -I{} mkdir another_folder/{}

Apply an operation on a file list coming from stdin, in this case make a copy of each .html file by appending a .bak extension:

    find . -iname "*.html" | xargs -I{} cp {} {}.bak

From the xargs man page for MacOS/BSD:

 -I replstr

         Execute utility for each input line, replacing one or more occurrences of

         replstr in up to replacements (or 5 if no -R flag is specified) arguments

         to utility with the entire line of input.  The resulting arguments, after

         replacement is done, will not be allowed to grow beyond 255 bytes; this is

         implemented by concatenating as much of the argument containing replstr as

         possible, to the constructed arguments to utility, up to 255 bytes.  The

         255 byte limit does not apply to arguments to utility which do not contain

         replstr, and furthermore, no replacement will be done on utility itself.

         Implies -x.

Linux xargs man page:

   -I replace-str

          Replace  occurrences of replace-str in the initial-

          arguments with names read from standard input.  Al‐

          so,  unquoted  blanks do not terminate input items;

          instead the separator  is  the  newline  character.

          Implies -x and -L 1.

When dealing with potentially unsanitized inputs, I like to see the entire job 'spelled out' line by line for visual inspection before I run it (especially when it's something destructive like cleaning people's mailbox's).

So what I do is generate a list of parameters (ie. usernames), feed it to a file in one-record-per-line fashion, like this:

johndoe  

jamessmith  

janebrown  

Then I open the list in vim, and mangle it with search and replace expressions until I get a list of full commands that need to get executed, like this:

/bin/rm -fr /home/johndoe  

/bin/rm -fr /home/jamessmith 

This way if your regex is incomplete, you will see in what command will have potential problems (ie. /bin/rm -fr johnnyo connor). This way you can undo your regex, and try it again with a more reliable version of it. Name mangling is notorious for this, because it's hard to take care of all the edge cases like Van Gogh, O'Connors, St. Clair, Smith-Wesson.

Having set hlsearch is useful for doing this in vim, as it will highlight all the matches, so you can easily spot if it doesn't match, or matches in an unintended way.

Once your regex is perfect and it catches all the cases you can test for/think of, then I usually convert it to a sed expression so it can be fully automated for another run.

For cases where the number of lines of input prevents you from doing a visual inspection, I highly recommend echoing the command to the screen (or better yet, a log) before it executes, so if it errors out, you know exactly which command caused it to fail. Then you can go back to your original regex and adjust once more.

If a program ignores the pipe but accepts files as arguments, then you can just point it to the special file /dev/stdin.

I am not familiar with java, but here is an example of how you would do it for bash:

$ echo $'pwd n cd / n pwd' |bash /dev/stdin

/home/rolf

/

The $ is necessary for bash to translate n into newlines. I'm not sure why.

I prefer this - allowing multi-line commands and clear code

find -type f -name filenam-pattern* | while read -r F

do

  echo $F

  cat $F | grep 'some text'

done

ref https://stackoverflow.com/a/3891678/248616