UNIX for Advanced & Expert Users

Originally Posted by alister

No, you did not. Your original attempt is not the same.

What you did:

Code:

grep -v '^#' | while read line; do ... done < server.cfg

What rangarasan suggested:

Code:

grep -v '^#' server.cfg | while read line; do ... done

There is a big difference. Pipe redirections occur before other redirection operations.

rangarasan is telling grep to read the file. Your original solution has grep reading something else (whatever standard input descriptor it inherited, which could be a teriminal or some other file).

You redirected the file directly to the while-read loop, bypassing grep. Your grep is doing nothing. Even if there is something for it to read on standard input (we can't tell from your script what stdin is, since it depends on how the script is called), there is nowhere for the grep data to go. Why? Because after the pipe connects the standard output of grep to the standard input of the while-read loop, the standard input of the while-read loop is overridden by the redirection operation immediately following the while-loop. So, even if grep does write to the pipe, there is nothing on the other end to read the data.

On a different note, there is no need for grep. Within the while-loop, a case statement can do the job:

Code:

case $line in
    \#*) continue ;;
esac

Or, if the shell supports substring parameter expansion:

Code:

[ "${line:0:1}" = '#' ] && continue

Regards,
Alister

Originally Posted by alister

ssh's standard input is the same descriptor that the while loop is reading. ssh is probably consuming some of the data. Try -n or explicitly overriding its stdin with /dev/null.

Regards,
Alister