He estado investigando diferentes intérpretes de línea de comandos y he notado que el intérprete predeterminado de Windows cmd.exeno se conoce como shell en elpágina de wikipedia. Prácticamente todos los intérpretes de línea de comandos de sistemas tipo Unix se denominan shells, pero no cmd.exela mayoría de los demás intérpretes.
¿Hay alguna razón para esto o "shell" es solo la nomenclatura para los intérpretes que pertenecen a sistemas tipo Unix?
Respuesta1
La concha esprincipalinterfaz de usuario al sistema operativo. En Windows esta interfaz es GUI. Se utiliza explorer.execomo "administrador de archivos", crea un "menú inferior", una "ventana de carpeta" y controla el proceso de apertura de archivos: cuando hace clic en el archivo, llama a ShellExecutela función.
Entonces, "shell" en Windows es la interfaz de usuario y "cmd" era solo para algunos comandos heredados o especiales. Durante muchos años, Microsoft pensó que la GUI era la mejor manera de hacer cualquier cosa.
En ~ 2006 descubrieron que los shells de Unix (bash, ksh, zsh) son muy populares entre los administradores de sistemas, por lo que inventaronPotencia Shell: sustitución de cmd basada en .net, lo cual es genial, especialmente si se usa con la última versión de Powershell ISE. Se llamacaparazónporque su objetivo principal es convertirse en "ciudadano de primera clase" para muchas tareas de administración de sistemas. Cualquier producto de servidor moderno de Microsoft tiene cmdlets para que pueda hacer casi cualquier cosa desde PowerShell (sin MMC).
No sé por qué no usaron la palabra "Shell" para "command.com" en la era MS-DOS. Podría ser que tomaron prestada terminología de CP/M y lo llamaron "procesador de comandos".
Es curioso: había un administrador de archivos GUI de corta duración "DOS Shell" para DOS. Se suspendió en 6.22 y la mayoría de la gente usaba Norton Commander en esa época.