Voici comment je vous suggère de le faire, et je vais expliquer pourquoi, mais je veux d'abord parler d'autre chose ...
set -- 'Arg 1: Line 1.' \
'Arg 2: Line 2.' \
'and so on for' \
'as long as you might like.'
var="$*"
Beaucoup des autres solutions proposées ici semblent suggérer que vous pouvez modifier le contenu d'une variable shell en modifiant vos méthodes d'extension. Je peux vous assurer que ce n'est pas le cas.
string="some stuff here \
some more stuff here."
echo $string ${#string}
echo "$string" "${#string}"
SORTIE
some stuff here some more stuff here. 53
some stuff here some more stuff here. 53
Ce que vous voyez ci-dessus est d'abord un développement par division de champ, puis un rapport sur le nombre d'octets pour la variable source du développement, puis un développement délimité par des guillemets et le même nombre d'octets. Bien que la sortie puisse différer, le contenu de la variable shell $stringne change jamais, sauf lors de l'affectation.
De plus, si vous ne comprenez pas pourquoi, il est certain que vous rencontrerez de très mauvaises surprises le plus tôt possible. Essayons encore, mais dans des conditions légèrement différentes.
IFS=sf
echo $string ${#string}
echo "$string" "${#string}"
Même $string- environnement différent.
SORTIE
ome tu here ome more tu here. 53
some stuff here some more stuff here. 53
La division de champ se produit en fonction des délimiteurs de champ définis dans $IFS. Il existe deux types de délimiteurs: les $IFSespaces et $IFStout le reste. Par défaut, $IFSl’ espace de valeur newline est affecté à l’ espace de valeur - qui sont les trois $IFSvaleurs d’espace possibles . Comme vous pouvez le constater ci-dessus, il est facile à modifier et peut avoir des effets considérables sur les développements en division de champ.
$IFSles espaces blancs vont élider par séquence en un seul champ - et c’est pourquoi echoun développement contenant une séquence d’espaces $IFScontenant un espace n’évaluera qu’un seul espace - car echoconcatène ses arguments sur des espaces. Mais toutes les valeurs non-blancs ne sera pas Elide de la même manière, et chaque delimiter se produit obtient toujours un champ à elle - même - comme on peut le voir dans la substance d' expansion ci - dessus.
Ce n'est pas le pire. Considérez cet autre $string.
IFS=$space$tab$newline
cd emptydir
string=" * * * \
* * * "
echo $string ${#string}
echo "$string" "${#string}"
SORTIE
* * * * * * 30
* * * * * * 30
Ça a l'air d'accord, non? Eh bien, modifions à nouveau l'environnement.
touch file1 file2 file3 file4 file5
echo $string ${#string}
echo "$string" "${#string}"
SORTIE
file1 file2 file3 file4 file5 file1 file2 file3 file4 file5 file1 file2 file3 file4 file5 file1 file2 file3 file4 file5 file1 file2 file3 file4 file5 file1 file2 file3 file4 file5 30
* * * * * * 30
Woah.
Par défaut, le shell développera les fichiers de noms de fichiers globs s'il peut leur correspondre. Cela se produit après le développement des paramètres et la division de champs dans son ordre d'analyse, de sorte que toute chaîne non mise entre guillemets est vulnérable de cette manière. Vous pouvez désactiver ce comportement set -fsi vous le souhaitez, mais tout shell compatible POSIX sera toujours glob par défaut.
C’est le genre de choses que vous rencontrez lorsque vous déposez des guillemets sur des extensions en fonction de vos préférences d’indentation. Et même ainsi, dans tous les cas, quel que soit son comportement d'expansion, la valeur réelle de $stringreste identique à ce qu'elle était lors de la dernière affectation. Revenons donc à la première chose.
set -- 'Arg 1: Line 1.' \
'Arg 2: Line 2.' \
'and so on for' \
'as long as you might like.'
var="$*"
echo "$var" "${#var}"
SORTIE
Arg 1: Line 1. Arg 2: Line 2. and so on for as long as you might like. 70
Je pense que c'est un moyen beaucoup plus sain d'adapter la syntaxe du shell à vos préférences d'indentation. Ce que je fais ci-dessus consiste à affecter chaque chaîne individuelle à un paramètre de position - qui peut être référencé par un numéro comme $1ou ${33}-, puis à attribuer ses valeurs concaténées à l' $varaide du paramètre shell spécial $*.
Cette approche n’est cependant pas à l’abri $IFS. Néanmoins, je considère que sa relation avec $IFSun avantage supplémentaire à cet égard. Considérer:
IFS=\ ;space_split="$*"
IFS=/; slash_split="$*";IFS='
';new_line_split="$*"
echo "$space_split"
echo "$slash_split"
echo "$new_line_split"
SORTIE
Arg 1: Line 1. Arg 2: Line 2. and so on for as long as you might like.
Arg 1: Line 1./Arg 2: Line 2./and so on for/as long as you might like.
Arg 1: Line 1.
Arg 2: Line 2.
and so on for
as long as you might like.
Comme vous pouvez le constater, $*concatène chaque argument dans "$@"le premier octet $IFS. Ainsi, enregistrer sa valeur pendant qu'elle $IFSest affectée différemment donne différents délimiteurs de champs pour chaque valeur enregistrée. Ce que vous voyez ci-dessus est la valeur littérale de chaque variable, au fait. Si vous ne vouliez pas de délimiteur, vous feriez:
IFS=;delimitless="$*"
echo "$delimitless" "${#delimitless}"
SORTIE
Arg 1: Line 1.Arg 2: Line 2.and so on foras long as you might like. 67