I believe the intention is to echo the variable's name, the equals sign, and the variable's value. If so, that statement is fine except for the lack of double quotes around $log_name (to protect the results of the parameter expansion from field splitting and pathname expansion).

Regards,
Alister

---------- Post updated at 01:00 PM ---------- Previous update was at 12:28 PM ----------

The UUofC is of no consequence compared to the fact that in many shells the use of a pipe relegates the reading while-loop to a subshell.

bakunin's helpful and informative post neglected to mention that if you do use a pipe, and if the while-loop runs in a subshell, all changes to the execution environment (such as variable assignments and redirections) will never be accessible to the parent shell. This alone could render the approach inconvenient if not infeasible.

If one truly, madly, deeply cares to avoid a redirection at the end of the while-loop, instead of piping cat into a while-loop, it's a better idea to use exec-redirection before the while-loop. Not only is it portable, the redirection just before the while-loop makes it clear from whence the input comes.

Code:

exec 4<&0 <inputfile
while read line; do
    ....
    ....
done
exec <&4 4<&-

You are mistaken. Double quoting a command substitution has no effect.

Double quoting only prevents parsing steps which are capable of generating additional fields -- field splitting and pathname expansion/globbing, for example. However, those steps are already bypassed during parameter assignment. So, those double quotes are harmless.

The behavior you describe is what would happen if the command substitution where single-quoted.


Regards,
Alister