Commande Sed qui fonctionne sur MacOS (au moins, OS 10) et Unix (c.-à-d. Ne nécessite pas gnu sed comme celui de Gilles (actuellement accepté)):
sed -e '/CLIENTSCRIPT="foo"/a\'$'\n''CLIENTSCRIPT2="hello"' file
Cela fonctionne dans bash et peut-être aussi dans d'autres shells qui connaissent le style de devis d'évaluation $ '\ n'. Tout peut être sur une seule ligne et fonctionner dans des commandes sed plus anciennes / POSIX. S'il peut y avoir plusieurs lignes correspondant à CLIENTSCRIPT = "foo" (ou votre équivalent) et que vous ne souhaitez ajouter la ligne supplémentaire que la première fois, vous pouvez la retravailler comme suit:
sed -e '/^ *CLIENTSCRIPT="foo"/b ins' -e b -e ':ins' -e 'a\'$'\n''CLIENTSCRIPT2="hello"' -e ': done' -e 'n;b done' file
(cela crée une boucle après le code d'insertion de ligne qui fait simplement défiler le reste du fichier, sans jamais revenir à la première commande sed).
Vous remarquerez peut-être que j'ai ajouté un '^ *' au modèle correspondant au cas où cette ligne apparaît dans un commentaire, par exemple, ou est en retrait. Ce n'est pas parfait à 100% mais couvre d'autres situations susceptibles d'être courantes. Ajustez au besoin ...
Ces deux solutions contournent également le problème (pour la solution générique consistant à ajouter une ligne): si votre nouvelle ligne insérée contient des barres obliques inverses ou des esperluettes, elles seront interprétées par sed et ne sortiront probablement pas de la même manière, tout comme l' \n
est - par exemple. \0
serait la première ligne correspondante. Particulièrement pratique si vous ajoutez une ligne qui provient d'une variable où vous auriez autrement à tout échapper en premier en utilisant $ {var //} avant, ou une autre instruction sed, etc.
Cette solution est un peu moins compliquée dans les scripts (que les guillemets et \ n ne sont pas faciles à lire cependant), lorsque vous ne voulez pas mettre le texte de remplacement de la commande a au début d'une ligne, par exemple, dans une fonction avec des lignes en retrait. J'ai profité du fait que $ '\ n' est évalué à une nouvelle ligne par le shell, ce n'est pas dans des valeurs simples '\ n' entre guillemets.
Cela devient cependant assez long pour que je pense que perl / même awk pourrait gagner en raison de sa lisibilité.