Cela est sorti d'un de mes commentaires à cette question concernant l'utilisation de bc dans les scripts shell. bc met les sauts de ligne en grand nombre, par exemple :
> num=$(echo 6^6^3 | bc)
> echo $num
12041208676482351082020900568572834033367326934574532243581212211450\ 20555710636789704085475234591191603986789604949502079328192358826561\ 895781636115334656050057189523456
Mais notez qu'ils ne sont pas vraiment des sauts de ligne dans la variable - ou du moins il n'y en a pas si elle est utilisée sans guillemets. Par exemple, en jouant avec plus de pipe dans le devoir, par exemple :
num=$(echo 6^6^3 | bc | perl -pne 's/\\\n//g')
J'ai réalisé que bien qu'il y ait vraiment un \n dans le bc sortie, vérification de echo $num > tmp.txt avec hexdump affiche le \n (ASCII 10) est définitivement devenu un espace (ASCII 32) dans l'affectation des variables.
Ou du moins, dans la sortie de $num > sans guillemets . Pourquoi est-ce ?
Comme le souligne fedorqui, si vous utilisez des guillemets :echo "$num" , vous obtenez à nouveau des retours à la ligne. Cela est évident en examinant la différence entre echo $num > tmp.1 et echo "$num" > tmp.2 avec vidage hexadécimal ; le premier contient \ (espace antislash) alors que ce dernier contient \\n (retour à la ligne).
Réponse acceptée :
echo met un espace entre chacun des deux arguments. Le shell considère la nouvelle ligne dans $num juste un séparateur de mots (comme un espace).
lines="a
b
c"
set -x
echo $lines # several arguments to echo
echo "$lines" # one argument to echo
Voir cette réponse (par le PO lui-même) pour une explication plus détaillée.