it-swarm-es.com

¿Por qué todavía se usan las consolas de terminal?

Como todos sabemos, las consolas de terminal provienen de una época en la que no había ninguna posibilidad de interfaces gráficas, por lo que la necesidad de ellas es más que obvia.

Con la aparición de interfaces gráficas, fueron posibles muchas aplicaciones nuevas, pero también la mayoría de esos programas de solo texto se trasladaron a su contraparte gráfica.

Sin embargo, los terminales persistieron, y no solo eso: hay servicios que generalmente mencionan esto como una característica. El ejemplo más común en la mano son los servicios de alojamiento.

Por supuesto, esto significa que, en lugar de hacer clic en un botón y editar un archivo, un usuario necesita memorizar cientos o miles de comandos y luego hacer algo como

Sudo nano /www/var/html/myfile.html

y luego navegue con un cursor gráfico para editar algo y luego ctrl+X y Y y elija el archivo para guardar. En otras palabras: la anti-usabilidad en su mejor momento (peor)

Lo mismo se puede ver para muchos otros comandos, lo anterior fue solo un ejemplo. Una muy fácil: WordPress 1-clic instalar vs instalar WordPress desde la línea de comandos

Entonces mi pregunta es: ¿hay una razón lógica por la que todavía se usan terminales? (básicamente, una razón tecnológica o una razón de seguridad) o es solo una cuestión cultural que persistió de alguna manera a pesar de todos sus problemas?

EDITAR: Agregar otro caso: git. Sé que hay GUI para git, y son mucho más fáciles de usar que git en la terminal. Entonces ... ¿por qué existe la versión del terminal?

114
Devin

Desde una perspectiva UX, las consolas de terminal tienen algunas ventajas clave sobre las GUI. Estas ventajas rara vez son relevantes para los usuarios finales, razón por la cual los CLI son utilizados casi exclusivamente por usuarios técnicos y "usuarios avanzados" actualmente.

Las cosas que se hacen en una terminal son fácilmente repetibles.

Imagine la necesidad de configurar 5 computadoras para algún propósito. Para este pequeño número, probablemente no valga la pena crear una solución automatizada para configurarlos a todos. Simplemente ajustará la configuración de cada uno.

En una terminal, es simple copiar y pegar los comandos. En una GUI, es posible que se familiarice con el lugar donde se almacenan las configuraciones, pero aún puede dejarlo haciendo un buen clic. Los errores son más probables.

Esto también es relevante para la documentación y la ayuda técnica. Proporcionar cuatro líneas para copiar y pegar en una consola de terminal podría reemplazar un par de párrafos de explicación sobre cómo hacer clic en varias herramientas de administración (especialmente dado que las instrucciones de la GUI pueden ser perfectas para una de varias interfaces, consulte "Las interfaces de la GUI son innumerables" a continuación ).

El seguimiento/auditoría es más fácil

Una interfaz de línea de comandos (CLI) retiene un registro de lo que ha hecho, que puede extraer y guardar fácilmente. Cuando algo sale mal, tu jefe pregunta: "¿Estás seguro de que lo hiciste exactamente bien?" puedes tener evidencia para demostrar que lo hiciste. Incluso si cometió un error, puede verlo más fácilmente y aprender de él.

La secuencia de comandos/automatización es casi tan fácil como ingresar comandos

Todos saben cómo usar un mouse para abrir un archivo en una GUI. Muchas menos personas saben cómo hacer que eso suceda automáticamente. Con una CLI, automatizar la tarea puede ser casi tan fácil como escribirla a mano.

Las restricciones tecnológicas aún pueden hacer que la CLI sea convincente

Iniciar sesión en un cuadro de GUI de forma remota requiere una gran cantidad de ancho de banda, y la latencia (retraso en la conexión) puede hacer que la experiencia sea frustrante. Un inicio de sesión remoto CLI tiene un requisito de ancho de banda mucho menor, ya que solo está transmitiendo un pequeño texto de ida y vuelta. Y la latencia es mucho más fácil de manejar cuando escribe, que cuando intenta pasar el mouse sobre un icono.

Se puede utilizar una CLI para entrada/salida

Algunos lo han llamado The Age of the API , donde los sistemas se construyen sobre los sistemas. Una CLI permite una interoperabilidad similar. En el ejemplo de la pregunta sobre Git, sería posible conectar otro "sistema empresarial", como un sistema de seguimiento de defectos.

En comparación con un SOAP o incluso Rest API, los comandos CLI pueden ser fáciles de desarrollar y probar.

Hay solo unos pocos depósitos estándar; Las interfaces GUI son innumerables

Si inicia sesión en la interfaz de administración de la GUI de algunos servicios de alojamiento web diferentes, probablemente verá que todos son diferentes. No es difícil hurgar y descubrir dónde está todo, pero lleva tiempo. El próximo año, el Host puede haber actualizado su solución, y ahora todo está en un lugar ligeramente diferente, una cosa más que aprender.

Ese servicio de alojamiento probablemente todavía usa la misma CLI. La nueva versión es retrocompatible con la anterior. Los usuarios familiarizados con Bash, PowerShell o cualquier CLI que se encuentre en el sistema pueden eliminar el tiempo de aceleración dedicado a familiarizarse (o volver a familiarizarse) con esa GUI en particular.

307
Tim Grant

En resumen: las líneas de comando son idioma ; El lenguaje da expresividad.


Un ejemplo de una interfaz de texto que utiliza: Búsqueda de Google . Imagínese si no pudiera escribir sus consultas como texto en Google y tuviera que seleccionar los documentos que deseaba de un menú de opciones (como el antiguo directorio web de Yahoo).


Jakob Nielsen, experto en usabilidad e investigador de experiencia de usuario, escribió con Don Gentner un artículo llamado "La interfaz Anti-Mac" :

Gentner, D. y Nielsen, J .: La interfaz Anti-Mac, Comunicaciones de ACM 39 , 8 (agosto de 1996), 70–82

En él, los autores señalan deficiencias en muchos principios que entran en interfaces "GUI". Por ejemplo,

Ver y señalar

El principio de ver y señalar establece que los usuarios interactúan con la computadora señalando los objetos que pueden ver en la pantalla. Es como si hubiéramos tirado un millón de años de evolución, perdido nuestras instalaciones con un lenguaje expresivo y reducido a señalar objetos en el entorno inmediato. Los botones del mouse y las teclas modificadoras nos dan un vocabulario equivalente a algunos gruñidos diferentes. Hemos perdido todo el poder del lenguaje y ya no podemos hablar sobre objetos que no son visibles de inmediato (todos los archivos tienen más de una semana de antigüedad), objetos que aún no existen (mensajes futuros de mi jefe), u objetos desconocidos (cualquier guía de restaurantes en Boston).

Ellos continuaron:

Si queremos pedir comida en un país donde no conocemos el idioma, nos vemos obligados a ir a la cocina y usar una interfaz de ver y señalar. Con un poco de comprensión del idioma, podemos señalar los menús para seleccionar nuestra cena del comedor. Pero el lenguaje nos permite discutir exactamente lo que nos gustaría comer con el camarero o el chef.

Puede valer la pena leer el artículo completo y contiene muchas respuestas a su pregunta.

Entonces el lenguaje (una línea de comandos) le permite tener una experiencia más rica. Pero como usted dice, esto no significa que el lenguaje sea ¡mejor, como se ilustra en este ejemplo que (probablemente por coincidencia) cambia claramente el ejemplo anterior:

Usar una interfaz de línea de comandos es como tener que aprender el idioma coreano completo solo para pedir comida en la sucursal de McDonalds en Seúl. Usar una interfaz basada en menús es como ser capaz de señalar la comida que desea y gruñir y asentir con la cabeza: transmite la misma información sin curva de aprendizaje.

- Joel Spolsky, ¡Diseño de interfaz de usuario para programadores, p. 76

¿Cuál es mejor , una GUI o una interfaz de texto? La interfaz de texto requiere más tiempo para aprender, a cambio de ser más expresiva y poderosa. Si vale la pena para usted depende de cuánto tiempo tenga la intención de vivir en ese entorno y de cuán rica sea la experiencia que le gustaría tener.

Las GUI de las aplicaciones contemporáneas generalmente están bien diseñadas para facilitar el aprendizaje, pero a menudo existe una compensación entre la facilidad de aprendizaje por un lado y la facilidad de uso, potencia y flexibilidad por otro lado. Aunque podría imaginarse una sociedad en la que el idioma fuera fácil de aprender porque las personas se comunicaban señalando palabras e íconos en los grandes menús que llevaban, los humanos optaron por invertir muchos años en dominar un lenguaje rico y complejo.

Tenga en cuenta que aprender el "lenguaje de línea de comandos" (un Bash-like Shell en un entorno similar a Unix, o quizás el equivalente de Windows) abre al alumno de inmediato una gran cantidad de experiencias potenciales. Muchos han optado por invertir en este aprendizaje, y por mi parte puedo decir que ha valido la pena.


Finalmente, para responder a su pregunta sobre por qué los servicios (como los servicios de alojamiento) anuncian interfaces de texto como una característica: imagine que está en un país extranjero donde muy pocos hablan inglés, que de alguna manera luchan con gestos y cosas similares, y ve una señal Un establecimiento que dice "Aquí hablamos inglés". (Del mismo modo, dependiendo de dónde viva, es posible que haya visto letreros que dicen "Se habla español".) La publicidad que menciona es similar: para aquellos que saben leer y escribir en la línea de comandos "idioma", esto equivale a una invitación a que puede esperar tener la rica experiencia de ser expresivo, sin limitarse a las interfaces gráficas que ya se han pensado e implementado.

256
ShreevatsaR

La versión larga

La respuesta está básicamente incluida en su propia pregunta:

un usuario necesita memorizar cientos o miles de comandos

Cambiar eso a cientos o miles de botones no sería una mejora en la usabilidad (e incluso si se hiciera, sería mucho más limitado que la línea de comando de texto).

Si intentara construir una GUI de uso general suficiente para cubrir cada tarea que se realiza en una ventana de terminal, su GUI sería inusualmente compleja o inusualmente limitada en funcionalidad para un subconjunto significativo de sus usuarios. Tome sus ejemplos, por ejemplo: "instalar con un clic" es excelente si lo único que desea es la configuración predeterminada, pero no es suficiente para nada más. La edición de un solo archivo en una terminal puede parecer compleja, pero los usuarios de la terminal rutinariamente encadenan múltiples utilidades de texto para propósitos específicos; trabajar en la línea de comandos suele ser mucho más similar a escribir programas cortos y de un solo propósito que hacer clic en un botón para realizar una tarea predefinida.

La mayoría de las tareas que se pueden mejorar moviéndolas desde la línea de comando a una GUI, ya lo han sido, si no desea usar nano ( o vi o emacs o lo que sea) no hay escasez de editores de texto basados ​​en GUI para elegir, por ejemplo. (Aunque si ya está en la línea de comando y solo necesita hacer un cambio rápido, es lo suficientemente rápido como para escribir vi y hacer esa edición rápida sin siquiera tocar el mouse).

Pero nadie jamás va a escribir una GUI capaz de, digamos, encontrar todos los archivos dentro de un directorio específico cuyo nombre coincida con un patrón dado, luego realizar una búsqueda y reemplazo dentro de ellos, envolver los originales en un tarball y empujarlo a otro servidor - porque eso sería una tarea increíblemente específica para una GUI para manejar. Pero cuando necesita hacer algo específico como eso, es simple juntar algunas utilidades de UNIX para hacerlo. Y para capturar eso en un script de Shell para que pueda hacerlo nuevamente cada semana a partir de ahora.

Los desarrolladores necesitan hacer cosas increíblemente específicas como esa todo el tiempo . El terminal es la IU más eficiente y fácil de usar para ese tipo de tarea.

La versión corta

La línea de comando se intercambia capacidad de descubrimiento, a cambio de eficiencia y flexibilidad.

El usuario debe haber aprendido los comandos con anticipación, no puede simplemente Excavar en menús y barras de herramientas para encontrarlos como en una GUI. Pero una vez aprendidas, todas esas herramientas están a solo un puñado de teclas, y se pueden combinar de formas novedosas según sea necesario (mientras que en una GUI cada tarea debe haber sido pensada de antemano por el diseñador).

Seguimiento en respuesta a comentarios

Los hilos de comentarios a lo largo de esta pregunta se han seleccionado un par de veces para conversar, pero dado que los mismos puntos parecen seguir apareciendo, me gustaría abordarlos aquí:

  • Realmente no necesitas miles de comandos, veinte o treinta lo harán.

¡Cierto! Algo así como. El problema es que los 20 o 30 comandos que necesita no serán necesariamente los mismos que necesita el próximo tipo: una GUI simplificada que contenga solo el subconjunto de comandos que utiliza habitualmente no será suficiente para ese otro tipo; y tampoco funcionará para usted, el primer día debe hacer algo que no sea de rutina.

(En segundo lugar, una vez que tiene en cuenta todas las diversas opciones de línea de comandos en cada uno de esos comandos, así como las formas en que se pueden canalizar de manera útil, realmente tiene más de 20 o 30 interacciones que deberían ser compatibles con su GUI personalizada ...)

Una GUI tiene que estar diseñada para un propósito particular. La línea de comando, por el contrario, es de propósito general: puede ser todo para todas las personas, porque si la funcionalidad que necesita no está integrada, puede agregarla usted mismo.

  • Ese ejemplo que diste de una tarea increíblemente sobreespecífica para la que nadie construiría una GUI: alguien lo hizo.

¡Cierto! Entré en ese, sí. Cambié el ejemplo para hacerlo un poco más increíblemente específico (pero no menos plausible).

Los contenedores GUI se han separado para muchas tareas de línea de comandos, y ciertamente son útiles (paso mucho más tiempo en la GUI de github que usar git en la línea de comandos, por ejemplo), pero cada uno de ellos es solo un subconjunto del muchos tipos de tareas para las que se usa la línea de comando; mi punto era más que ninguna GUI razonable podría cubrir todos , o incluso en cualquier lugar cercano a la mayoría , tareas de línea de comandos. (O, diablos, incluso aquellos por solo git en sí; todavía necesito volver a la línea de comando para las cosas que la interfaz gráfica de usuario no puede manejar).

  • Descubrimiento ("La línea de comando es más reconocible de lo que crees"/"Las GUI no son tan reconocibles como crees")

Estoy usando el término "detectable" en su sentido estricto aquí: un nuevo usuario puede descubrir cómo usar un programa simplemente usando el programa. es decir, si solo lo golpeas durante el tiempo suficiente, podrás descubrir cómo funciona sin recurrir a recursos externos. (Definitivamente no digo que esa es la única o la mejor manera para que un usuario aprenda a usar algo; solo que es una ventaja potencial que tienen las GUI sobre la CLI.)

Con mucho gusto reconoceré que las interfaces GUI mal diseñadas no necesariamente facilitan la capacidad de detección.

No estoy de acuerdo con los varios comentarios (algunos eliminados, otros aún actuales) que sugieren que la línea de comando facilita la capacidad de detección, en cualquier grado real. Si tiene que leer la página man para descubrir cómo usar una función, eso no es detectable; Eso es aprender. Lo cual es genial, pero es algo diferente. No creo que haya suficiente consistencia en las opciones de la línea de comandos para varias herramientas como para argumentar que aprender una herramienta te ayuda a entender las otras; y no hay una forma razonable para que un usuario de la CLI descubra la existencia de herramientas que aún no conoce (no, ls /usr/bin no es suficiente; eso es más análogo a "darme el índice del manual, en orden alfabético".) Hay algunos ayudantes y accesos directos, como completar pestañas, pero son más útiles como recordatorio después de haber aprendido algo de lo que son. una forma de aprenderlo en primer lugar.

93
Daniel Beck

Entonces mi pregunta es: ¿hay una razón lógica?

Las personas pueden escribir más rápido que usar un mouse.

Una anécdota:

En una vida pasada formé parte de un pequeño equipo que trabajaba en una pieza de software para un nicho de mercado. Esto fue en los años 90 cuando la pieza de software dominante en el mercado había sido una herramienta de línea de comandos. Este grupo demográfico no era necesariamente experto en tecnología, por lo que creamos un software que era mucho más fácil de aprender dado que tenía una GUI.

Tuvo un éxito modesto pero, al final, nunca pudimos destituir al líder de la industria. Parte de eso podría atribuirse al hecho de que simplemente eran la opción incorporada y siempre es un desafío molestar al titular. Pero una gran parte de nuestra incapacidad para ganar clientes del otro software fue que las personas que habían trabajado en la herramienta de línea de comando me gusta ella. Conocían los comandos, eran rápidos con él y podían hacer todo rápidamente con unas pocas teclas.

Entonces, si bien era una herramienta bastante difícil de aprender, una vez que se aprendió, fue una herramienta increíblemente poderosa y rápida.

La lección aprendida para mí fue que las GUI no son mejores ni peores que las terminales/líneas de comando. Son simplemente diferentes. A veces, uno es mejor que el otro para tareas particulares, pero es imposible decir que uno es simplemente mejor que el otro. Todo depende.

55
DA01

Yo argumentaría por dos razones principales, ninguna de las cuales es universal. Pero, ambas razones son muy buenas para preferir hacer al menos algunas cosas en la línea de comando:

  • Programabilidad Es mucho más fácil codificar contra el estándar IO que manipular mediante programación una GUI - o escribir integraciones personalizadas para el corredor macro para cada aplicación con la que desea automatizar o integrar.
  • Eficiencia. Cuando quieres editar myfile.html, ya conoce el nombre del archivo y el editor que desea usar. Muy a menudo, es más rápido escribir lo que estás pensando que traducir lo que estás pensando en una serie de movimientos coordinados del mouse en un GUI jerárquica: para encontrar su editor y para encontrar su archivo. (Es notable que la tendencia en la GUI ha sido proporcionar mini consolas, en las que simplemente puede escribir el nombre del programa que desee ...)

En tu ejemplo:

Sudo nano /www/var/html/myfile.html

Si ya sé, necesito editar myfile.html como administrador, y si estoy familiarizado con mi interfaz de usuario (la consola y mi editor habitual) me toma de 2 a 3 segundos escribir esto:

Sudo nano /w <tab> v <tab> h <tab> m <tab> <enter>

Cuando ya estoy en mi directorio de trabajo, me lleva aproximadamente 1 segundo abrir un archivo en vim si sé el primero 1 o 2 letras del archivo que estoy buscando.

Eso es incluso más rápido que cuando tengo una solución ya cargada en un IDE - incluso cuando conozco la ruta completa y nombre de archivo. En una GUI, tengo que escanear visualmente y navegar por una jerarquía alfabetizada para encontrar mi archivo. Para mí, eso es probablemente de 5 a 15 segundos, dependiendo de qué tan grande es la jerarquía de archivos.

No parece mucho, pero se siente como mucho. Y, si entra y sale de cientos o miles de archivos y operaciones en esos archivos por día, los 4 a 14 segundos adicionales por archivo pueden ser notables. (Especialmente si su jefe lo está comparando con su contraparte del asistente de línea de comando ...)

46
svidgen

Una interfaz de línea de comando (CLI) no es tan hostil como la pregunta lo hace sonar. Podríamos argumentar de manera similar que una interfaz de apuntar y hacer clic es mala porque oculta elementos internos y dificulta la composición de comandos complejos.

Imaginemos un niño pequeño que aún no habla, sino que señala las cosas. Sí, realiza algunas tareas, como pedir pan o beber en la mesa. Pero una vez que el niño aprende a hablar, rara vez vuelve a señalar. Esto sugiere que hablar es más poderoso que señalar y gruñir. Sin embargo, en el futuro, no reemplazamos todo por escribir cartas.

Ahora, muchas interfaces gráficas de usuario son como el ejemplo secundario, señalar y hacer clic. La interfaz de la línea de comandos está más cerca de hablar con un software, o incluso de pensar de manera más apropiada en enviar mensajes de texto a un amigo que es un poco más exigente que hablar.

En un mundo ideal, no pensaría que una CLI es una antítesis horrible de UX, sino un complemento de la GUI. No tiene que ser uno u otro. Al igual que un adulto en un país extranjero puede volver a señalar. Debería poder elegir qué es apropiado para la tarea.

Algunas ideas falsas

  • Una línea de comando requiere que aprenda miles de comandos.

    Por el contrario, generalmente necesita saber una docena como máximo para ser efectivo. Al igual que en una interfaz gráfica de usuario, aún necesita saber lo que está haciendo. En muchos lugares donde tienes muchas aplicaciones instaladas, terminas en el mismo problema. Simplemente no puede usar el programa XYZ a menos que conozca el nombre del programa XYZ y lo encuentre en la GUI para que lo inicie.

    Saber que nano es un editor de texto es obviamente algo memorable, tanto como saber que el bloc de notas es un editor.

  • Una línea de comando es difícil de aprender

    En realidad no, generalmente es muy simple. Sin embargo, dado que solo los usuarios algo avanzados lo usarían, significa que a menudo está orientado hacia ellos. Eso no significa que el concepto sea difícil; solo que no es para uso casual.

  • una línea de comando es menos reconocible que la GUI

    Algunas veces las GUI son, otras no. Las interfaces de línea de comandos son reconocibles, al menos las buenas. Del mismo modo, no todas las GUI son muy utilizables. De hecho, una interfaz de línea de comandos muy mala es mejor que una GUI incorrecta. La línea de comando es accionable: puede encapsular fácilmente la línea de comando incorrecta para satisfacer adecuadamente sus necesidades. Una mala GUI es una mala GUI: no hay mucho que se pueda hacer al respecto.

  • Una GUI es más fácil de usar

    A veces, cuando se realizan tareas simples que estaban destinadas a hacer, eso es cierto. Sin embargo, a veces la gente se atasca por cosas ridículamente simples que son triviales de hacer, pero la GUI simplemente no te permite hacer eso. En una línea de comandos, esto generalmente no es un problema: simplemente tome algún otro comando para ayudarlo.

¿Una línea de comando tiene mala experiencia de usuario?

¡Solo si está mal diseñado! Las líneas de comando y los comandos vienen en diferentes paquetes al igual que las GUI. La mayoría de ellos no son particularmente elegantes. Sí, la mayoría de las aplicaciones GUI también son malas. Algunas aplicaciones de línea de comandos tienen un diseño increíblemente bueno y ofrecen una buena experiencia de usuario, mientras que otras no.

No hay nada inherentemente malo en una línea de comando. De hecho, he descartado las aplicaciones como malas porque no tenían una interfaz de línea de comandos para hablar. También he usado algunas aplicaciones durante años, incluso cuando su GUI es mala porque tienen una buena interfaz de línea de comandos. YMMV.

PS : Es sorprendente lo que puedes hacer con un bucle. Lo que pasarías días haciendo a mano se puede hacer en segundos. Si valoras tu propio tiempo, utilizas la línea de comando.

38
joojaa

Bueno, uso terminales para casi todo, pero algunas cosas como la edición de imágenes. Me gustaría compartir mis razones para hacerlo, centrándome en la experiencia del usuario.

shell es un lenguaje para la composición de programas

Los terminales (y los shells) son los que me permiten tener una conversación con mi computadora. No uso la terminal para hacer cosas; Lo uso para comunicar mi intención al sistema y hacer que lo haga por mí.

Por ejemplo, con un Shell puedo hacer tareas incrementalmente más complejas. Todo lo que puedo hacer a mano, puedo decirle al sistema que lo haga por sí mismo.

# report status of service
systemctl status mariadb

# do it on foo.com
ssh foo.com "systemctl status mariadb"

# do it for bar-1.foo.com through bar-8.foo.com
for i in {1..8}; do ssh bar-$i.foo.com "systemctl status mariadb"; done

Tenga en cuenta que estos tres comandos a su vez no requieren volver a escribir nada si conoce las combinaciones de teclas de Shell para la navegación del historial y la edición de la línea de comandos, la expansión del historial, o incluso copiar y pegar. El resultado de cada comando estará en la terminal para una fácil revisión y comparación. Absolutamente todo se puede copiar y pegar en cualquier parte del sistema.

El equivalente al último comando con una interfaz gráfica de usuario requeriría que inicie sesión en cada sistema a través de un protocolo de escritorio remoto y verifique manualmente el estado de cada servicio moviendo un mouse y haciendo clic en los iconos, enviando coordenadas y clics del mouse y recibiendo un video que contenga un fondo de pantalla y ventanas y menús emergentes. No habrá una manera simple de comparar los resultados uno al lado del otro. Necesitaría el protocolo para manejar portapapeles compartidos y copiar los resultados a un archivo en mi computadora local, o manejar tantas conexiones pesadas y cambiar el tamaño de las ventanas para ocultar los fondos de pantalla y esas cosas.

Ok, ahora quiero que me envíen un correo electrónico si uno de ellos cae.

while true; do
    for i in {1..8}; do
        echo "==> bar-$i.foo.com"
        ssh bar-$i.foo.com "systemctl status mariadb"
    done > /tmp/services.txt
    if grep '^\s*Active:' /tmp/services.txt | grep -qv running; then
        mail -s "service failed!" [email protected] < /tmp/services.txt
    fi
    sleep 10m
done &

Suficientemente simple. Ahora, como no tengo idea de cómo extraer información de una interfaz gráfica de usuario renderizada (OCR?), No puedo hacer el equivalente con la interfaz gráfica de usuario.

El problema que estoy tratando de resolver con la interfaz gráfica es que no tengo forma de decirle al sistema cosas como for i in {1..8} o if grep ... con la interfaz gráfica de usuario, y es realmente engorroso decirle "mueva el mouse a esta coordenada, haga doble clic y espere este tiempo estimado antes de hacer clic en esta nueva ventana ...", y suponiendo que pueda adivinar dónde aparecerá una nueva ventana ...

Puedo hacer cosas con la interfaz gráfica de usuario, pero no es un idioma. No puedo decir lo que quiero hacer, así que puede hacerlo por mí. Debo hacerlo yo mismo.

fácil de comunicar

¿Cómo darías instrucciones para hacer una tarea específica a otras personas? En una interfaz gráfica de usuario, tendría que decirles que hagan clic en el zorro, luego en la hamburguesa (si entienden ese término), menú, menú, menú, pestaña, clic, salir, clic, etc. A veces es útil publicar capturas de pantalla de la interfaz gráfica de usuario con grandes flechas rojas que apuntan a donde deben ir.

Con comandos, solo ... escríbelos. Si las acciones son demasiado complejas y confían en usted, simplemente pueden copiar y pegar los comandos y terminar con ellos.

acciones almacenables

Esto puede ser obvio, pero puede combinar un conjunto complejo de comandos, ponerlos en un archivo y ejecutarlo ... es pura automatización; ¿Cómo puede una GUI competir con eso?

Asignaciones de teclas de Shell, globbing, expansión de llaves, expansión de historial, etc.

Creo que la mayoría de las personas que se quejan del Shell, lo hacen porque terminan escribiendo de manera muy repetitiva (también podría ser porque todavía requiere mucho más escribir, aunque diría que eso es una ventaja).

El Shell tiene muchas características que hacen que trabajar con él sea extremadamente eficiente. El problema es que debes aprender sobre esas características. Todo está en man bash y man zshall. Es demasiado incluso para arañar la superficie aquí.

Bueno, el punto aquí es que Shell proporciona muchas facilidades para reducir la repetición en su trabajo. La GUI de programas específicos puede ser algo similar a través de la funcionalidad del historial y similares, pero Shell funciona para prácticamente todo.

terminal scrollback-buffer e historial de Shell

Configuré mi terminal para guardar las últimas 100000 líneas para mostrar. Si dejo mi computadora por un tiempo o no vuelvo a visitar una terminal en algún momento, siempre puedo retroceder y ver qué he hecho con cualquier programa (terminal). Obtuve mi configuración de Shell Prompt para mostrar una marca de tiempo antes y después de ejecutar un comando. Siempre puedo decir cuánto tiempo se ejecutó un comando sin ejecutarlo preventivamente con time. Es tan simple, pero ¿cómo harías eso con una interfaz gráfica de usuario? ¿Implementar algún tipo de reproducción de video para que el escritorio siempre esté grabando?

También tengo el Shell para guardar los últimos 2000000 comandos en un archivo de historial. Si miro el archivo, no solo tiene los comandos, cada uno tiene una marca de tiempo de cuando lo ejecuté. Hace unos meses, mi jefe me pidió que hiciera una tarea que hice unos meses después de ser contratado. No puedo recordar ahora, pero recuerdo que no podía recordar entonces. Eran múltiples comandos complejos que involucraban algún conjunto de servidores. Afortunadamente, todavía tenía los comandos en el archivo de historial. Fue increíblemente fácil encontrarlos y volver a ejecutarlos. Estaba tan impresionado que aumenté el límite de tamaño de mi historial en dos órdenes de magnitud. ¿Qué harías en esta situación si todo lo que hicieras fuera con una interfaz gráfica de usuario?

más simple de programar

Los programadores también son usuarios. La facilidad para escribir programas de terminal también es parte de la experiencia del usuario, y ciertamente es una razón por la cual se escriben tantos programas nuevos para que funcionen para un terminal.

No tiene que lidiar con la creación de ventanas y widgets, y algunos bucles de representación. Simplemente obtiene sus argumentos de una matriz e imprime algo de texto en la salida estándar.

La programación para un terminal en lugar de una interfaz gráfica de usuario también tiene otra implicación: archivos de configuración de texto destinados a ser editados a mano. ¿Cuándo fue la última vez que usó un programa GUI y se esperaba que lo configurara abriendo un archivo, editándolo y luego reiniciando un programa? Un usuario de un programa de interfaz gráfica de usuario espera poder configurarlo a través de la interfaz gráfica de usuario.

Para el programador, esto significa que no solo tiene que escribir y leer la configuración en archivos, sino que también debe implementar widgets para ello.

Como el programador esperará que el usuario use los widgets, editar el archivo de configuración a mano probablemente será una experiencia subóptima. Para el usuario, esto también tiene inconvenientes:

  • no podrá compartir fácilmente la configuración con otras computadoras y amigos.
  • no podrá poner comentarios al respecto, ya que se sobrescribirán.
  • puede ser problemático rastrear cambios en el control de versiones.

entrada y salida única

Cuando tengo problemas con algún programa y el mensaje de error no es muy útil, lo ejecuto con strace. La salida de strace y el programa se combinan, y luego puedo ver qué causó el error justo antes de imprimir el mensaje que me preocupa. Si el programa no termina después del primer error, también puedo pasar la salida a sed '/message/q' o similar para que elimine el programa cuando se imprime el mensaje.

Si estoy depurando en una interfaz gráfica de usuario, el error probablemente aparecerá en alguna ventana emergente, y el mensaje no habrá pasado a través de alguna llamada al sistema. Puedo imprimir todo lo que el programa hizo con strace, pero encontrar el error en la salida sin parar requerirá más búsqueda de la que me gustaría. Los programas de GUI también tienden a hacer más cosas para hacer el mismo trabajo, por lo que el culpable del error probablemente estará oculto entre muchas líneas de llamadas del sistema que pasan mensajes que apenas son relevantes para la tarea que necesitaba hacer.

24
JoL

En una palabra: disiconia. Esa es mi propia moneda, por analogía con la dislexia, y significa que me cuesta muchísimo tratar de descubrir qué significan las estúpidas imágenes de una GUI típica. Sé que se supone que son intuitivos, pero para mí no lo son. Creo que esto podría ser cierto para más personas de las que sospecharía, o ¿por qué si las GUI a menudo agregan texto debajo de sus iconos?

Por supuesto, con el uso prolongado, memorizaría algunos íconos comunes (aunque todavía no puedo entender por qué se supone que son 'intuitivos'), pero me enfrento a uno nuevo y una vez más no tengo ni idea. Peor aún, no hay una buena manera de buscar una imagen **. Con un comando desconocido, simplemente puedo ejecutar "man strange_command", buscar en el índice del manual del programa o usar una búsqueda en Google.

Los humanos son criaturas naturalmente verbales; después de todo, el lenguaje es lo que se supone que nos distingue del resto de los animales, ¿no es así? Para aquellos de nosotros que usamos idiomas alfabéticos, un buen vocabulario de lectura en nuestro idioma nativo sería más de 50,000 palabras. (Las personas con múltiples idiomas pueden agregar fácilmente 10K o más por idioma, dependiendo de la fluidez). Podemos buscar palabras desconocidas en un diccionario o deducir su significado del contexto. Agregar los pocos miles (no cientos de miles) necesarios para usar una CLI a esta base se hace fácilmente.

Todo esto significa que para la mayoría de las personas alfabetizadas *, usar un terminal/CLI es solo una extensión fácil de las habilidades que ya tienen. Una vez que uno se familiariza con él, generalmente es superior a los métodos gráficos para cualquier tarea que no sea inherentemente gráfica (como dibujar).

PD para @nekomatic: Para evidencia, ¿qué tal esto? http://www.pewresearch.org/fact-tank/2015/10/19/slightly-fewer-americans-are-reading-print-books- new-survey-find / Literalmente, el primer enlace encontrado buscando "porcentaje de estadounidenses que no leyeron un libro este año". Desde el enlace "Alrededor del 27% de los adultos dijeron que no habían leído ningún libro en el último año ..." y "El número medio de libros leídos por mujeres fue de cinco, en comparación con una mediana de tres para hombres ..." Si eso no es analfabetismo funcional, ¿qué es?

* Sospecho que la popularidad de las GUI va de la mano con el aumento del analfabetismo funcional. Asimismo, entrada y salida de voz.

** Incluso los idiomas ideográficos como el japonés (y creo que el chino, aunque nunca lo he estudiado) tienen sistemas para buscar kanji en un diccionario.

19
jamesqf

Puede que esté en el sitio equivocado, pero ...

La experiencia del usuario no es el único programa de conducción forzada

Hacer y modificar un programa es mucho más simple si solo se ocupa de la entrada y salida del terminal.

Los humanos no son los principales usuarios de los programas de terminal

El comando en una terminal es el mismo que usa la máquina detrás de la mayoría de los gráficos, esto es algo muy bueno para probar partes de cosas complicadas. Casi todas las líneas que se ejecutan a través de una terminal llaman a más de un programa al vincularlas, el gráfico que obtengo de una interfaz gráfica de usuario agradable puede hacer que sea fácil aprender sobre algo rápidamente, pero no me ayuda a decirle a la máquina qué hacer al respecto .

y porque estoy aquí: foco

Después de usar mucho cualquier programa, sabes exactamente dónde buscar la información que deseas (si el escritor no es un imbécil), tener texto no es un obstáculo una vez que has subido la curva de aprendizaje, y no cambias el enfoque a Hacer el próximo cambio posiblemente usando un programa diferente es positivo.

14
user94222

Por dos razones simples

  1. Funciona
  2. Es poderoso

Solo para agregar a lo que se había dicho, porque al final del día, una GUI es solo un bonito front-end para una utilidad de línea de comandos.

Cada vez que hace clic en un botón, se emite un comando. Hay acciones que no tienen un botón, pero nunca habrá un botón con una acción que no podrá realizar en el terminal.

Como ejemplo, en Windows puede hacer clic derecho en cualquiera de sus iconos de acceso directo en su escritorio y podrá encontrar allí el comando que se ejecuta una vez que hace doble clic en él. Puede ingresarlo directamente en una consola de terminal y se ejecutará la misma acción.

En Windows es más difícil apreciar la simplicidad y el poder de la línea de comando porque su Shell carece de muchas características útiles presentes en los shells de Linux, como la finalización de pestañas, por ejemplo.

8
Mario Chapa

Compatibilidad con versiones anteriores y sistemas integrados

Ese sistema de 30 años que ejecuta la aviónica en un B-52 todavía tiene que mantenerse. Al igual que el microcontrolador de la bomba que alimenta la torre de agua, o el sistema que ejecuta las cintas transportadoras en mi fábrica.

Recuperación de desastres

El sistema tarda más tiempo en activar la GUI desde un inicio en frío, tiempo que quizás no tenga. Si necesito tener una máquina de respaldo funcionando en este momento fuera de un dispositivo de almacenamiento externo en una situación de vida o muerte, no quiero quedarme sentado por 60 segundos adicionales.

Monitoreo remoto, diagnóstico y administración

Esto se aplica especialmente cuando se encuentra en una situación de ancho de banda limitado. Si mis enlaces de comunicaciones de banda ancha primarios, secundarios y terciarios han fallado, pero todavía tengo un módem de 56k, no voy a arrastrar ese circuito hacia abajo enviando datos GUI sobre él. Voy a usar una CLI para iniciar sesión de forma remota en los enrutadores para poder descubrir qué está mal y hacer que vuelvan a funcionar.

8
John Feltz

Creo que el terminal es una mejor solución para usuarios avanzados. Puede llevarlo directamente a la acción, puede realizar cualquier tipo de tarea avanzada con él y es fácil de desarrollar.

A veces la terminal es inevitable. Algunas cosas simplemente no se pueden hacer en una interfaz gráfica, por lo que debe hacerlo en el terminal.

Algunas personas, como yo, prefieren el terminal a las interfaces gráficas para algunas aplicaciones. Por ejemplo, ejecuto un bot, y el terminal es mi entorno de desarrollo ideal para aplicaciones codificadas (también uso herramientas GUI para codificarlo, pero el terminal siempre es mi opción para ejecutarlo).

4
Dev

Para ser breve (más o menos), dado que se han proporcionado una serie de buenas explicaciones, hay muchos sistemas esenciales en los que implementar una GUI simplemente no es práctico. Esta suele ser la situación con cualquier servidor que solo va a hacer un puñado de cosas y debe asegurarse de que tenga todos los recursos disponibles solo para esas tareas. Si algunas de esas tareas implican servir una aplicación GUI, debe aprovisionarse para eso, pero si todo lo que un servidor va a hacer es servir páginas web, solo querrá programas absolutamente necesarios para que no haga nada más que servir esas páginas.

Los programas GUI siempre tendrán un procesamiento y almacenamiento de datos significativamente mayor que la mayoría, si no es que ninguno, del programa de línea de comandos solo debido a la naturaleza de requerir más información.

Git es otro gran ejemplo. Lo usará principalmente en servidores a cientos/miles de millas de distancia para los cuales solo puede interactuar a través de una terminal para que se le asignen recursos mínimos para comunicarse con el servidor. En ese momento, querrá estar muy familiarizado con la línea de comandos para poder trabajar con ella tan cómodamente como un programa GUI.

4
Spencer Williams

Control y precisión.

El uso de terminal necesita el conocimiento de los comandos que lo hacen funcionar. No es intuitivo ni fácil para el principiante. Pero una vez que el usuario conoce los comandos, mucha de la funcionalidad es más rápida de escribir que encontrar el elemento en la interfaz e interactuar con el mouse.

Algunas de las funcionalidades de las interfaces gráficas pueden estar detrás de los umbrales de seguridad que protegen al usuario de sí mismo. sando comandos en la consola, el usuario tiene control absoluto sobre lo que hace.

3
Alvaro

Algunas respuestas se han acercado pero ninguna dio en el blanco.

La razón más importante para los programas terminales. Lo primero y más fácil de presentar a un usuario es una cara textual. Esta cara textual está en el idioma del usuario. Necesita la mínima cantidad de potencia informática e interfaz para permitir la comunicación frente a todo lo que se requiere para presentar una GUI. Además de eso, una GUI requiere mucha más memoria y recursos informáticos y potencia solo para llegar al punto donde estaría un terminal. Una GUI también requiere un hardware más sofisticado que pueda mostrarlo. Los LED simples pueden presentar toda la información textual necesaria para ejecutar los servidores más potentes, pero no pueden mostrar más que gráficos muy simples.

Después de eso, con respecto a algo para hacer clic, la capacidad de ingresar comandos de lenguaje humano supera con creces el poder que uno puede usar marcando casillas o haciendo clic en los botones. El alcance y la precisión que se pueden transmitir en unas pocas palabras simples es de largo alcance y sin restricciones. ¿Qué hace uno si el color "chartreuse" no es una de las casillas de verificación pero es una opción en el programa?

2
Rob