sed es una herramienta presente en cualquier sistema UNIX. Se trata de un editor de texto en modo streaming. Aunque sed es una herramienta muy potente, con un lenguaje de programación propio que es Turing completo, la mayor cantidad de usos son sustituir o extraer datos usando expresiones regulares y los comandos s y p. jq es sed para el siglo XXI porque trabaja de forma nativa con JSON, es decir, trabaja con objetos, no con texto plano.
|
etiquetas: jq , json , sed , expresión regular , editor de texto , editor de json
Pues la que lo usa habitualmente y la que sabe mirar la ayuda
Una de las ventajas fundamentales de de UNIX es poder trabajar con archivos de texto plano.
Por lo que entiendo de los comentarios (efectivamente, no me he leído el envío), jq vendría a ser una especie de sed, pero pensado para ficheros json (definición de objetos en javascript), es decir, que en lugar de búsqueda y reemplazo por línea, como hace sed, lo haría por objeto javascript.
Con jq puedes procesar un CSV y hacer filtrados y extracciones complejas que hasta con awk serian un dolor de huevos de hacer. No es sólo para JSON.
diaaño,voto por los buenos tiempos de meneame donde la mayoria de las discusiones eran de este tipo.
Porque manda huevos....
Antes que enseñar jq mejor aprende sobre configurar un servidor web.
grep, sed y awk son herramientas basadas en expresiones regulares, que procesan los ficheros de texto línea a línea. JSON es un formato de serialización de objetos, posiblemente anidados. Es matemáticamente imposible analizar una estructura recursiva mediante expresiones regulares. La jerarquía de Chomsky, el lema del bombeo, y esas cosas que se estudian en la carrera. Te pueden servir para tareas muy sencillas, como buscar o sustituir una determinada palabra, pero ya está, para tareas más complejas necesitas herramientas más potentes.
De todos modos, decían por ahí que sed era turing-completo.... me pareció raro, pero no conozco sed lo suficiente.
Por ejemplo si no utilizas JSON es mucho más sencillo definir variables incluyendo un fichero de texto plano en un script que si utilizas JSON.
Imagina un script de arranque/parada de un demonio en /etc/init.d
¿Cuanto complica el script utilizar un fichero de configuración en JSON en lugar de los tipicos ficheros en texto plano con las variables y comentarios?
Acabarías con que la parte dedicada a leer el JSON es más grande que el propio script de arranque/parada.