Bash: saut de ligne à la fin d'une variable : disparait. why?

Saut de ligne

gnugo -
gnugo - 30 janv. 2013 à 12:56

Bonjour,
Je suis confronté à un nouveau problème, voyez par vous même :

$ echo -e "\na\nb\n\n"

a
b


$ a="$(echo -e "\na\nb\n\n")"
$ echo "$a"

a
b
$ cat <<<"$a"

a
b
$

Je n'arrive pas à enregistrer/afficher dans une variable des sauts de ligne s'ils se trouvent à la fin

Y a t-il un moyen de faire cela ?

Merci d'avance

Afficher la suite

A voir également:

Bash retour à la ligne
Retour à la ligne chatgpt - Forum Réseaux sociaux
Aller à la ligne lors de la rédaction d'un message ✓ - Forum MacOS
Comment faire un retour à la ligne automatique d'un texte long en php ou sql? - Forum PHP
Retour à la ligne excel - Guide
Retour à la ligne google sheet - Forum Excel

6 réponses

Réponse 1 / 6

zipe31 Messages postés 34620 Date d'inscription Statut Contributeur Dernière intervention 6 499

Salut,

Fait le contraire :

$ a="\na\nb\n\n"

$ echo -e "${a}" | cat -A
$
a$
b$
$
$

;-))

Réponse 3 / 6

Utilisateur anonyme

salut,

c'est le comportement normal de bash lors des substitutions de commandes.

une solution (vue sur le wiki de bash-hackers.org) consiste à faire un echo supplémentaire d'un signe quelconque, et de l'enlever

$ var=$(printf '%s\n\n\n' "foo bar"; echo "x")    
$ var="${var%%$'\n'x}"    
$ echo "$var"    
foo bar   


$

gnugo

Merci
Tordu de faire ainsi, mais à défaut d'autre solution je prends ! J'ai cherché également sur le net sans rien trouver sur ce sujet.
Une solution passant par un fichier temporaire au lieu d'une variable fonctionne aussi mais c'est beaucoup moins performant.

Si quelqu'un a une autre solution pour, en bash, stocker en mémoire le retour d'une commande qui contient plusieurs "\n" à la fin, ça m'intéresse :)

zipe31 Messages postés 34620 Date d'inscription Statut Contributeur Dernière intervention 6 499

Salut,

Effectivement, la solution parait logique une fois qu'on a compris que c'est le comportement par défaut.

Par contre je suis surpris de constater qu'il n'existe pas une option (avec "shopt") pour annuler ce comportement ;-\

Merci pour la solution.

Réponse 4 / 6

dubcek Messages postés 18810 Date d'inscription Statut Contributeur Dernière intervention 5 653

hello
autre méthodd

$ var=$(printf '%s' "foo bar") 
$ var+='\n\n\n'
$ echo -e "$var"
foo bar



$

zipe31 Messages postés 34620 Date d'inscription Statut Contributeur Dernière intervention 6 499

Salut dubcek,

Euh... non ;-\
Ça marche pas ton truc, lui c'est les "\n" déjà présent dans le retour de commande qu'il veut voir :

var=$(printf '%s\n\n\n' "foo bar")

Il ne sait pas à l'avance s'il existe un, plusieurs, voire pas du tout de "\n", d'où la méthode de "qqchquicommenceparQ" ;-)

gnugo

oui exactement :-)

Réponse 5 / 6

gnugo

Bonjour,

Je reviens vers vous car la solution précédente ne fonctionne pas toujours.
Et ça bloque au niveau du "${var%%x}" : Lorsque ma variable est d'une taille importante (dans mon test je l'ai copié dans un fichier, elle fait 7Mo) le script se bloque.

En déroulant manuellement c'est au moment où la substitution se fait que ça bloque, un echo "${var%%x}" me met un cpu à 100% et bloque le process, au point qu'un ctrl +Z ou ctrl +C ne change rien, seul un kill -9 le tue

Et en le laissant tourner 2h, toujours rien.
Même si la taille de la variable est conséquente, un ralentissement serait compréhensible mais là c'est un vrai blocage, ce n'est pas un comportement normal.

Avez vous le même souci ?

Du coup j'en reviens à vous demander s'il y a une autre solution :/

Merci

dubcek Messages postés 18810 Date d'inscription Statut Contributeur Dernière intervention 5 653

une variable de 7 Mo n'a pas beaucoup de sens, il faudrait faire autrement, dans un fichier par ex.

gnugo

N'ayant pas besoin de stocker ces données volatiles, je n'ai pas vu l'intérêt de les stocker sur le disque.
Elles sont récupérées d'un flux réseau, traitées en mémoire sur ma machine (comparées en totalité), puis envoyées dans un autre flux

(C'est un cas très particulier ces 7Mo.)

Je ne peux pas "mettre en pipe" ce traitement car je dois d'abord recevoir les données en totalité avant de les traiter. D'où le stockage en mémoire.
Il s'agit de données de l'ordre de 1 à 20 lignes de texte en général, et exceptionnellement plus, qui ne dépassera jamais l'ordre de quelques Mo . Dans ce contexte je ne vois pas l'intérêt de passer par un fichier

dubcek Messages postés 18810 Date d'inscription Statut Contributeur Dernière intervention 5 653

les variables ne sont pas faites pour qelques Mo.
tu passes par un fichier temporaire /tmp/xxx$RANDOM que tu supprimes après traitement

gnugo

C'est ce que je constate en bash.
Va pour les accès disque alors.

Merci

dubcek Messages postés 18810 Date d'inscription Statut Contributeur Dernière intervention 5 653

ou peut-être utiliser un tableau plutot qu'une simple variable, peut-être bash supporte une grande taille

Réponse 6 / 6

gnugo

Bonjour,

N'existe t-il pas un moyen de modifier le comportement par défaut, afin que les nouvelles lignes à la fin ne soient pas tronquées ?

dubcek Messages postés 18810 Date d'inscription Statut Contributeur Dernière intervention 5 653

dans quel cas ?

gnugo

Toujours le même cas, conserver les nouvelles lignes lors de l'enregistrement du retour d'une commande

exemple :
var="$(echo -ne 'texte\n.\n\n\n\n')"

Discussions similaires

Retour à la ligne tchat.

Saut à la ligne trop grand dans word 2010

saut de ligne sur shell

Faire un retour à la ligne sur Google Sheet

Comment supprimer des sauts de lignes dans une cellule ?

Saut de lignes sans <br/>

Discussions similaires

Newsletters