¿Guión Vs de una sola línea?

He notado muchas preguntas y respuestas y comentarios que expresan desdén (y a veces incluso miedo) por escribir guiones en lugar de frases ingeniosas. Entonces, me gustaría saber:

• ¿Cuándo y por qué debo escribir un guión independiente en lugar de uno “de una sola línea”? ¿O viceversa?

• ¿Cuáles son los casos de uso y las ventajas y desventajas de ambos?

• ¿Algunos lenguajes (p. ej., awk o perl) se adaptan mejor a las frases ingeniosas que otros (p. ej., python)? Si es así, ¿por qué?

• ¿Es solo una cuestión de preferencia personal o hay buenas razones (es decir, objetivas) para escribir uno u otro en circunstancias particulares? ¿Cuáles son esas razones?

Definiciones

• one-liner :cualquier secuencia de comandos escritos o pegados directamente en una línea de comandos de shell . A menudo involucra canalizaciones y/o uso de lenguajes como sed , awk , perl y/o herramientas como grep o cut o sort .

  La característica definitoria es la ejecución directa en la línea de comandos:la longitud y el formato son irrelevantes. Un "one-liner" puede estar todo en una sola línea, o puede tener varias líneas (por ejemplo, sh for loop, o código awk o sed incrustado, con saltos de línea y sangría para mejorar la legibilidad).

• script :cualquier secuencia de comandos en cualquier idioma interpretado que se guarda en un archivo , y luego ejecutado. Un guión puede estar escrito completamente en un idioma, o puede ser un envoltorio de guión de shell en torno a múltiples "una línea" usando otros idiomas.

Tengo mi propia respuesta (que publicaré más adelante), pero quiero que se convierta en una sesión canónica de preguntas y respuestas sobre el tema, no solo en mi opinión personal.

Respuesta aceptada:

Otra respuesta basada en la experiencia práctica.

Usaría una sola línea si fuera un código de "desechado" que pudiera escribir directamente en el aviso. Por ejemplo, podría usar esto:

for h in host1 host2 host3; do printf "%s\t%s\n" "$h" "$(ssh "$h" uptime)"; done

Usaría un script si decidiera que vale la pena guardar el código. En este punto, agregaría una descripción en la parte superior del archivo, probablemente agregaría alguna verificación de errores y tal vez incluso lo registraría en un repositorio de código para el control de versiones. Por ejemplo, si decidiera que verificar el tiempo de actividad de un conjunto de servidores es una función útil que usaría una y otra vez, la línea anterior podría expandirse a esto:

#!/bin/bash
# Check the uptime for each of the known set of hosts
########################################################################
#
hosts=(host1 host2 host3)

for h in "${hosts[@]}"
do
    printf "%s\t" "$h"
    uptime=$(ssh -o ConnectTimeout=5 -n "$h" uptime 2>/dev/null)
    printf "%s\n" "${uptime:-(unreachable)}"
done

Generalizando, se podría decir

• De una sola línea

  • Código simple (es decir, solo "algunas declaraciones"), escrito para un propósito específico único
  • Código que se puede escribir rápida y fácilmente cuando sea necesario
  • Código desechable

• Guión

  • Código que (probablemente) se usará más de una o dos veces
  • Código complejo que requiere más que "unas pocas" declaraciones
  • Código que deberá ser mantenido por otros
  • Código para ser entendido por otros
  • Código que se ejecutará sin supervisión (por ejemplo, desde cron )

Veo una buena cantidad de preguntas aquí en unix.SE que solicitan una sola línea para realizar una tarea en particular. Usando mis ejemplos anteriores, creo que el segundo es mucho más comprensible que el primero y, por lo tanto, los lectores pueden aprender más de él. Una solución se puede derivar fácilmente de la otra, por lo que en aras de la legibilidad (para futuros lectores), probablemente deberíamos evitar proporcionar código comprimido en una línea para cualquier cosa que no sea la más trivial de las soluciones.

Relacionado:¿expansión de nombre de ruta de bash/shell para mkdir, touch, etc.?