Comando Sed que funciona en MacOS (al menos, OS 10) y Unix por igual (es decir, no requiere gnu sed como lo hace Gilles (actualmente aceptado)):
sed -e '/CLIENTSCRIPT="foo"/a\'$'\n''CLIENTSCRIPT2="hello"' file
Esto funciona en bash y quizás también en otros shells que conocen el estilo de cotización de evaluación $ '\ n'. Todo puede estar en una línea y funcionar en comandos antiguos / POSIX sed. Si puede haber varias líneas que coincidan con CLIENTSCRIPT = "foo" (o su equivalente) y solo desea agregar la línea adicional la primera vez, puede volver a trabajarla de la siguiente manera:
sed -e '/^ *CLIENTSCRIPT="foo"/b ins' -e b -e ':ins' -e 'a\'$'\n''CLIENTSCRIPT2="hello"' -e ': done' -e 'n;b done' file
(esto crea un bucle después del código de inserción de línea que simplemente pasa por el resto del archivo, sin volver nunca más al primer comando sed).
Puede notar que agregué un '^ *' al patrón coincidente en caso de que la línea aparezca en un comentario, digamos o esté sangrada. No es 100% perfecto, pero cubre algunas otras situaciones que probablemente sean comunes. Ajuste según sea necesario ...
Estas dos soluciones también resuelven el problema (para la solución genérica para agregar una línea) de que si su nueva línea insertada contiene barras invertidas o símbolos sin escape, serán interpretados por sed y probablemente no saldrán de la misma manera, tal como \n
es, por ejemplo. \0
Sería la primera línea coincidente. Especialmente útil si está agregando una línea que proviene de una variable donde de lo contrario tendría que escapar de todo primero usando $ {var //} antes, u otra declaración sed, etc.
Esta solución es un poco menos desordenada en los scripts (sin embargo, citar y \ n no es fácil de leer), cuando no desea colocar el texto de reemplazo para un comando al comienzo de una línea, por ejemplo, en una función Con líneas dentadas. Aproveché que $ '\ n' es evaluado a una nueva línea por el shell, no está en valores regulares '\ n' entre comillas simples.
Se está haciendo lo suficientemente largo, aunque creo que perl / incluso awk podría ganar debido a que es más legible.