Muy bien recuerdo los inicios de los 90’s. Usar una computadora u ordenador implicaba conocerse los comandos básicos del MS-DOS (ver3.x~5.0 en esos entonces); Tux estaba en pañales luego de que Linus Torvalds publicara la primera versión.
Conocida también como consola, línea de comandos, intérprete de comandos, CLI, shell, bash, la terminal es vilipendiada en estos tiempos como algo del pasado. Los detractores de GNU/Linux recurren comunmente a mencionar esta «desventaja» y lo han hecho su caballito de batalla. Pero es claro que es motivo de terror para quienes estan acostumbrados al Point&Click&Ok&Next. Usarla no siempre es necesario, pero si se convierte en algo muy útil para realizar algunas tareas, para agilizarlas, e incluso, recuperar nuestro sistema cuando de modo gráfico definitivamente no se puede.
Si usted usa esos aparatos para picar verduras y frutas significa que debe de tirar los cuchillos? Creo que no. Es muy probable que usted tenga que usar la línea de comandos en Linux, pero con la ayuda que hay en internet esto se vuelve una trivialidad.
Está incluida en los sistemas basados en Unix, tales como BSD, GNU/Linux, Mac OS X y Solaris.
bash es un shell de Unix (intérprete de comandos de Unix) escrito para el proyecto GNU. Su nombre es un acrónimo de bourne-again shell — otro shell bourne — haciendo un juego de palabras (born-again significa renacimiento) sobre el Bourne shell (sh), que fue uno de los primeros shells importantes de Unix.
Hacia 1978 el shell Bourne era el shell distribuido con el Unix Version 7. Stephen Bourne, por entonces investigador de los Laboratorios Bell, escribió el shell Bourne original . Brian Fox escribió el shell bash en 1987.
Si bien es cierto los entornos gráficos han evolucionado considerablemente, despreciar el cursor del intérprete de comandos conlleva más desventajas que nada; por ejemplo, en los sistemas Windows de la famosa Microsoft se empezó a desestimar la línea de comandos desde que surgio Windows 2000, siendo necesario contar con el disco de instalación para recuperar el entorno gráfico que no se lograba solucionar en el Modo a Prueba de Fallos. Sin embargo el shell DOS esta presente todavía en los sistemas Windows, mutilado de su antiguo poder, pero presente.
La CLI en sistemas *nix nos permite darnos cuenta como se está ejecutando un proceso y que falla o podría estar fallando, así como recuperar o matar (KILL) procesos problemáticos.
El intérprete de comandos es de gran ventaja para el manejo y administración de paquetería en las diversas distribuciones GNU/Linux o BSD; nos ahorra cantidad de trabajo en unas cuantas líneas; hay más rapidez en el proceso de descarga/instalación de paquetes. Cuando hacemos uso de una aplicación en modo texto nos ahorramos la carga de su interface gráfica en RAM y ganamos tiempo en la ejecución del proceso. Se convierte en la única opción cuando la interface gráfica no nos responde por algún problema.
Afortunadamente es posible contar con un sistema *nix en modo gráfico y depender 0% de la línea de comandos. Lógico que eso dependerá del uso y necesidades del usuario en su equipo.
Qué puede ser más rápido para conocer tus procesos en ejecución? Irte al monitor de procesos o tipear un comando de tres o cinco caracteres?
Linux On My Time 