Dies ergab sich aus einem meiner Kommentare zu dieser Frage bezüglich der Verwendung von bc im Shell-Scripting. bc setzt Zeilenumbrüche in großen Zahlen, z.B.:
> num=$(echo 6^6^3 | bc)
> echo $num
12041208676482351082020900568572834033367326934574532243581212211450\ 20555710636789704085475234591191603986789604949502079328192358826561\ 895781636115334656050057189523456
Beachten Sie jedoch, dass es sich nicht wirklich um Zeilenumbrüche in der Variablen handelt – oder zumindest nicht, wenn sie ohne Anführungszeichen verwendet wird. Zum Beispiel beim Herumalbern mit mehr Pfeifen in der Zuweisung, z. B.:
num=$(echo 6^6^3 | bc | perl -pne 's/\\\n//g')
Mir wurde klar, dass es zwar wirklich einen \n gibt im bc Ausgabe, überprüfen Sie echo $num > tmp.txt mit hexdump zeigt den \n (ASCII 10) ist definitiv ein Leerzeichen (ASCII 32) in der Variablenzuweisung geworden.
Oder zumindest in der Ausgabe von $num > ohne Anführungszeichen . Warum ist das so?
Wie fedorqui betont, wenn Sie Anführungszeichen verwenden:echo "$num" , erhalten Sie wieder Zeilenumbrüche. Dies wird deutlich, wenn man den Unterschied zwischen echo $num > tmp.1 untersucht und echo "$num" > tmp.2 mit Hexdump; Ersteres enthält \ (Backslash-Leerzeichen), während letzteres \\n enthält (Backslash Zeilenumbruch).
Akzeptierte Antwort:
echo setzt ein Leerzeichen zwischen jeweils zwei Argumente. Die Shell berücksichtigt den Zeilenumbruch in $num nur ein Worttrennzeichen (genau wie Leerzeichen).
lines="a
b
c"
set -x
echo $lines # several arguments to echo
echo "$lines" # one argument to echo
Siehe diese Antwort (vom OP selbst) für eine ausführlichere Erklärung.