¿Cómo se ve un sistema operativo sin un shell?

Un shell como bash o command.com (hasta Windows ME) o CMD.EXE (en versiones posteriores) proporciona una interfaz que (entre otras cosas) acepta comandos del usuario. ¿Cómo se ve un sistema operativo antes de ejecutar un shell? ¿Cómo se utilizaron los sistemas antes de que se desarrollara el primer shell (por ejemplo, UNIX a principios de la década de 1970)? Si una computadora ni siquiera puede aceptar comandos (no hay línea de comando), ¿cómo puede un usuario interactuar con ella? ¿Cuál es esta interfaz más básica? ¿Puedo ejecutar esta interfaz en un emulador de terminal o no hay forma de ir detrás de un shell?

¿Cómo se ve un sistema operativo antes de ejecutar un shell?

Depende del sistema operativo y de cómo lo configure. Linux se puede configurar para escribir texto de arranque en un dispositivo de consola, ya sea una consola de modo de texto, una consola de framebuffer o un puerto serie. También se puede configurar para que sea perfectamente silencioso. Algunos sistemas operativos / sistemas operativos pueden escribir información de diagnóstico en una memoria no volátil a la que se puede acceder poniendo el sistema en modo desarrollador, depuración o diagnóstico. Muchos sistemas operativos admiten la salida de información de inicio y diagnóstico a alguna forma de UART, que de alguna manera puede estar disponible en la unidad incluso si está oculta para el usuario (google "Agregar puerto serie a DD-WRT" para ver ejemplos de dónde los fabricantes ocultan puertos serie y cómo puedes llegar a ellos).

Un sistema operativo no tiene que tener una pantalla externa, es solo otro dispositivo para el sistema operativo.

¿Cómo se utilizaron los sistemas antes de que se desarrollara el primer shell (por ejemplo, UNIX a principios de la década de 1970)?

Esencialmente (y omitiendo mucho, pero esto debería darle la idea): cargó su programa, ya sea accionando interruptores en un panel o usando un lector de cinta de papel (estos dispositivos escribirían en la memoria directamente sin intervención de la CPU) y luego comenzarán La CPU con otro interruptor. La CPU ejecuta este programa, genera su salida y se detiene. Este es el procesamiento por lotes en lugar de procesamiento interactivo. Si deseaba ejecutar un programa diferente, tenía que volver a hacerlo.

Si una computadora ni siquiera puede aceptar comandos (no hay línea de comando), ¿cómo puede un usuario interactuar con ella?

No soy un experto en esta área, pero las computadoras viejas y viejas como Altair, IMSAI y PDP-8 y tales tenían interruptores en el panel frontal que controlaban directamente la CPU y podían leer y escribir memoria directamente sin intervención de la CPU.

¿Cuál es esta interfaz más básica?

Creo que la mayoría, si no todas las CPU modernas tienen un "puerto JTAG" que permite el mismo tipo de operaciones directas. Tenga en cuenta que durante mucho tiempo se esperaba que la mayoría de las computadoras tuvieran ROM o firmware que toma el control del sistema cuando se enciende antes de pasarlo a un sistema operativo. Aquí, pueden existir utilidades previas al arranque, o existe un mecanismo mínimo para cargar tales utilidades. Se puede acceder a algunos cargadores de arranque como U-Boot a través del puerto serie. Los cargadores de arranque no se ejecutan "detrás" del sistema operativo, cargan el sistema operativo, controlan manualmente y ya no se ejecutan.

¿Puedo ejecutar esta interfaz en un emulador de terminal o no hay forma de ir detrás de un shell?

No, necesitas una interfaz JTAG. Eso es sumergirse en el ámbito de la electrónica y admito que no sé mucho al respecto, excepto que mi GuruPlug viene con uno y puedo programar directamente el chip flash en la placa del GuruPlug con él, lo que significa que si algo mata al gestor de arranque en el GuruPlug, tengo una forma "independiente de la CPU" de actualizarlo.

Un sistema operativo no tiene que proporcionar un shell, ya que el término se usa comúnmente hoy en día (es decir, una aplicación que aceptará comandos interactivamente del usuario), pero dicho sistema operativo realmente no "se verá" en absoluto para nada usuario. Como menciona Oliver Salzburg, probablemente solo mostraría una pantalla en blanco (si tiene soporte de salida de pantalla), aunque no hay razón para que tenga que hacerlo. Tomemos, por ejemplo, la salida de diagnóstico del kernel de Linux durante el proceso de inicio y de inicialización del kernel.

El shell, ya sea un shell gráfico, un intérprete de línea de comandos u otra cosa, utiliza las facilidades proporcionadas por el sistema operativo para hacer cosas como leer comandos, iniciar procesos, redireccionar E / S, etc.

Sin embargo, no hay ninguna razón por la cual la aplicación que utiliza esas instalaciones tiene que ser un shell .

En los viejos tiempos, los sistemas operativos eran simplemente una colección de esas "rutinas útiles" que cada aplicación tendría que reescribir desde cero, y las computadoras eran esencialmente dispositivos de procesamiento por lotes. Cosas como E / S de archivos, discos e impresoras fueron probablemente las primeras en ser recopiladas en lo que ahora se conoce como sistema operativo, seguidas de la programación de procesos (vale la pena señalar que la computadora de orientación Apollo de principios de la década de 1960 era una computadora multitarea) Las aplicaciones podrían hacer llamadas al sistema operativo en lugar de usar sus propias rutinas para hacer esas cosas, lo que redujo la complejidad de la programación y probablemente ayudó a reducir el tamaño del código o el tiempo de ejecución (porque esas instalaciones del sistema podrían optimizarse y depurarse una vez, lo que beneficiaría a todos) . A medida que las computadoras se volvieron cada vez más comunes, los sistemas operativos agregaron características que se centraron en gran medida en el usuario, como una forma para que el usuario interactúe con la computadora y dé comandos de manera interactiva; los shells gráficos son simplemente una extensión de esa línea de razonamiento.

Además, no hace mucho tiempo (piense hasta fines de la década de 1980), todavía era bastante común escribir aplicaciones para ejecutarlas en el hardware de la computadora personal, sin la ayuda de ningún sistema operativo ordinario. Esto fue particularmente útil para los juegos, ya que evitó la sobrecarga de memoria y procesamiento del sistema operativo propiamente dicho, pero estoy seguro de que también hubo otros ejemplos. En esos casos, hasta cierto punto, la aplicación era su propio sistema operativo y, en consecuencia, la interfaz de usuario proporcionada por esa aplicación era el shell.

Las primeras computadoras no tenían un sistema operativo en el sentido en que usamos la palabra hoy. Expusieron funciones implementadas en hardware directamente a cualquier programa que se ejecute en él. Solo había un programa ejecutándose en ellos al mismo tiempo. El programa en sí tenía que controlar todas las tareas, nada fue hecho "en segundo plano" por un sistema operativo.

Pero todavía había un punto de entrada para que el usuario iniciara un programa. Si estira la palabra, podría llamar a esto un "caparazón". Pero, básicamente, era solo el hardware que esperaba que el usuario ingresara el primer bit del programa a ejecutar. Ya sea en forma de botones presionados, interruptores movidos, cables conectados en una centralita, tarjetas perforadas, película perforada o cinta magnética. Tal vez incluso podrían elegir entre varias opciones de programa cargadas anteriormente. Pero incluso la selección de una lista que se muestra como luces brillantes al presionar un botón al lado ya puede considerarse un 'shell'.

Entonces, si su definición de 'shell' es 'una interfaz que acepta comandos de un usuario', entonces no hubo tiempo antes, al menos para dispositivos que incluso llamarían vagamente a una computadora.

Es posible que desee consultar la muy buena página de Wikipedia sobre la historia de la informática , aunque no se centra mucho en la perspectiva de entrada / salida.

Probablemente será una pantalla en blanco.

El shell probablemente se llama shell porque es un shell alrededor del núcleo (el núcleo es el sistema operativo). Entonces, en cierto sentido, es la interfaz de usuario para el sistema operativo, sea cual sea la interfaz que sea.

Si un sistema operativo solo tuviera una única función, que sería apagar la computadora, y construiría un programa que acepte cualquier entrada de teclado y luego invoque esa función, entonces ese es el shell. No es necesario tener una interfaz de línea de comandos compleja para construir algo que interactúe con el usuario.

Desde un punto de vista histórico, supongo que hubo tarjetas perforadas ( https://en.wikipedia.org/wiki/Punched_card ). Para interactuar con un sistema informático. Pero supongo que esto es demasiado atrás para su pregunta.

El primer sistema operativo que utilicé (1981) después de la universidad fue PRIMOS en una minicomputadora Prime. Este era un sistema operativo de tiempo compartido y admitía una cantidad de usuarios, cada uno de los cuales usaba un terminal conectado a la computadora a través de un cable RS232. Debes iniciar sesión en la terminal con un nombre de usuario y contraseña. Su sesión terminal fue una especie de caparazón. Podrías editar archivos, compilar, ejecutar todas esas cosas que hacemos hoy en día. Todos los terminales tenían acceso al mismo sistema de archivo. En gran medida, estos terminales no eran más que máquinas de escribir, no editores WYSISWYG, incluso emacs era un sueño.

El sistema operativo estaba estructurado como está ahora y podría imaginarse como una capa de pieles de cebolla. La capa más interna tenía una funcionalidad de nivel muy bajo, como control de hardware, acceso a memoria. Yendo hacia afuera, se agregaría el sistema de archivos y luego las capas de usuario. En su programa, podría interactuar con algunas capas, pero no con las más internas (por lo que no podría meterse con el tiempo compartido o el hardware real, luces, etc.). Una computadora sin shell sería como una de estas capas internas, podría acceder a un disco duro y un lector de cinta (¡en serio!), Pero no sabría sobre archivos o usuarios.

Para iniciar una computadora temprana, necesitaba cargar un conjunto básico de instrucciones (esto podría implicar alternar interruptores físicos en una secuencia establecida en la computadora). Esta secuencia iniciaría un segundo programa pequeño, que podría permitir que el lector de cintas funcione. Luego cargaría un sistema más complejo a través del lector de cintas, lo que podría poner en línea la unidad de disco. Podrías imaginar un sistema operativo sin shell como uno de estos cargadores iniciales.

Hoy en día, las computadoras tienen secuencias similares, por lo que cuando inicia la máquina, carga su BIOS, que inicia los discos, las tarjetas de red, la tarjeta de video, etc., luego el BIOS busca un programa específico en el disco duro y lo ejecuta (en Windows al menos). Unix hace algo similar, configura progresivamente el kernel comenzando con módulos muy básicos y construyéndolos hasta que llegue al indicador de inicio de sesión

El sistema operativo como definición es bastante ambiguo. ¿Es un núcleo en sí mismo? ¿Es el núcleo y también las herramientas que lo acompañan? Linux es el kernel pero GNU / Linux es el sistema operativo basado en el kernel de Linux y las herramientas de proyecto GNU. Shell es una parte integral de dicho sistema operativo.

Sin embargo, una vez que Linux esté listo y "terminado", debe indicarle qué programa ejecutar. A partir de entonces, todo está en manos de ese programa en particular. De forma predeterminada, es lo initque sabe qué hacer a continuación y, eventualmente, puede llevarlo a una buena pantalla de inicio de sesión de GUI. Pero no tiene por qué ser así. Puedes arrancar así

kernel /boot/vmlinuz-2.6.30 root=/dev/sda1 ro init=/bin/fancy

Entonces el programa /bin/fancyimprimirá "¡Hola mundo!". No necesitamos shell para eso. Si desea iniciar algún otro programa, simplemente genere un nuevo proceso con man 2 forky man 2 execve, o lea desde el dispositivo terminal y acepte la entrada del usuario. Todavía no hay necesidad de concha.

En mi opinión, el shell del sistema operativo es un programa capaz de leer la entrada del usuario y luego iniciar otros programas. Si lo piensa, es bastante obvio por qué le gustaría escribir un programa de este tipo.

Incluso si no necesita leer la entrada del usuario de forma interactiva, es mucho más conveniente escribir un script de shell simple para su tarea. En ese caso es solo intérprete de comandos de shell almacenados. También puede escribir su programa en intérprete de algún otro idioma.

Los sistemas operativos sin shells de línea de comandos o interfaces gráficas tienen muchos otros tipos de "caras".

Los sistemas integrados solo hacen su trabajo sin ninguna interfaz de usuario, como el sistema de gestión del motor de su automóvil (que puede acceder de alguna manera a través de la interfaz OBD2 y un terminal adecuado). O puede tener teclados digitales, perillas o lo que sea (piense: horno de microondas, elevador o la placa frontal de un sistema de sonido moderno). Si usted considera esto como una forma de caparazón es subjetivo, por supuesto.

Aquí hay una receta de alto nivel de cómo, como aficionado, puedes hacer una computadora útil sin un caparazón:

• Construya una placa de circuito para un microcontrolador u obtenga una placa genérica.
• Conéctelo para manejar algunos dispositivos útiles, como, por ejemplo, un sensor de humedad y una válvula de agua. El microcontrolador tiene pines periféricos para este propósito: UART, GPIO, etc.
• Escriba el firmware para monitorear el sensor y riegue la tierra.
• Cargue el firmware a través de las herramientas de desarrollo (por lo tanto, no se requiere shell en la computadora host para cargar y ejecutar nada, y el firmware se almacena en la memoria flash en el chip). La programación puede implicar que el microcontrolador se conecte a una placa de programación especial, o puede haber una forma de hacerlo mientras está sentado en su placa real. La placa se conecta a su PC (hoy en día a través de USB, por ejemplo) y utiliza algunas herramientas: como un IDE o herramientas de línea de comandos en el host.
• Implemente la cosa: ahora es esencialmente una caja negra electrónica que de alguna manera monitorea la humedad del suelo y enciende el agua, sin otras entradas o salidas.

Las primeras computadoras de uso general sin conchas tenían algunos medios de entrada, como leer tarjetas perforadas. Pero, por supuesto, las tarjetas perforadas tenían que distinguirse: ¿una tarjeta perforada le da a la computadora algún comando especial, o es parte de un programa Fortran? Así que se tuvieron que desarrollar "lenguajes de control de trabajo", que son líneas de comando de facto.

Antes de las tarjetas perforadas y los lenguajes de control de trabajos, los programadores tenían que alternar los interruptores para alimentar el código binario en la máquina. Es posible que haya escuchado historias de veteranos que tuvieron que "alternar" la secuencia de instrucciones para iniciar un arranque. Esto todavía se hace hoy, de alguna manera: todavía existen dispositivos que tienen puentes o interruptores DIP, y hay algunas ventajas en comparación con la configuración del firmware.

La primera computadora en la que me quedé atrapado fue un Siemens 305 en 1977, estaba aprendiendo FORTRAN IV. Tenía una máquina de escribir para ejecutar comandos e imprimir mensajes de diagnóstico en papel, un lector de tarjetas perforadas, un lector / grabador de cintas perforadas y una impresora. Sin olvidar el disco duro extraíble de 40 MB, de 16 pulgadas más o menos. Entonces ya tenía un shell, y la interfaz era la máquina de escribir.

Recuerdo ejecutar un depurador y editor de texto (DDT y emacs) como el equivalente de un shell de comandos en la década de 1970. Entonces, si ejecuta emacs en modo consola con cualquier otro programa ejecutado a través de eshell a un depurador que ejecute el programa, tendrá una experiencia cercana.

Tenga en cuenta que emacs tiene un entorno lisp completo, por lo que además de una buena edición del historial de comandos y múltiples terminales virtuales, tiene una función de macro y scripting muy capaz incorporada.