Nicolas Sebrecht <nicolas.s.dev@xxxxxx> writes:
> It really seems like the argument has precedence to the redirection
> I couldn't find any reference to this case in POSIX and I guess that the
> behaviour may differ between implementations of sed.
> Perhaps somebody could tell us if our hesitation is justified (or not)?
If you give file arguments, standard input is irrelevant to sed. I bet you
do:
$ sed -e something file
all the time, and you rely on the command not to get stuck after reading
the file because now it wants to continue reading from its stdin, which is
connected to your terminal. Have you ever worried about having to type ^D
after every such invocation of sed? I bet you never have ;-)
Also, your _preferred_ alternative
{ read l1; read l2; read l3;
( echo "$l1"; echo "$l2"; echo "$l3"; cat | sed )
} <"$1"
is not just simply inefficient, but is actively wrong. The "read" can
butcher your input. For example, try:
$ echo "a b " | ( read l1; echo "<$l1>" )
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html