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' \nest - par exemple. \0serait 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é.