Pregunta, tema de discusión

Estoy muy interesado en la generación de código fuente de shell de línea de comandos a partir de código escrito en un lenguaje compilado más robusto, de buen desempeño e independiente de la plataforma (OCaml, por ejemplo). Básicamente, programaría en un lenguaje compilado para realizar cualquier interacción con el sistema operativo que desee (lo propondría: las interacciones más complejas o las que no son fáciles de realizar de manera independiente de la plataforma), y finalmente lo compilaría a un ejecutable binario nativo (preferiblemente), que generaría un script de shell que efectúa en el shell lo que programó en el lenguaje compilado. ElADICIONAL]: Con 'efectos', me refiero a establecer las variables de entorno y las opciones de shell, ejecutar ciertos comandos no estándar (el 'compilador' de scripts estándar sería manejado por el ejecutable compilado y se mantendría fuera del script de shell generado) y tal.

No he encontrado ninguna solución de este tipo hasta ahora. Parece ser relativamente fácil de realizar * en comparación con otras posibilidades actuales, como compilar OCaml a JavaScript.

¿Hay ya implementaciones (públicas) de lo que describo?¿Cuáles son otras posibilidades que son (muy) similar a lo que describo, y en qué se diferencian de eso? (La compilación de lenguaje a lenguaje (de compilado a sh) viene a la mente, aunque parece innecesariamente difícil de realizar).

Lo que hagono media

Una cáscara alternativa (como Scsh). Es posible que los sistemas que administre no siempre permitan que los shells sean seleccionados por el usuario o por un administrador, y también espero que sea una solución de administración de sistemas exclusivamente para otros (clientes, colegas y otros), así como las personas a las que no se puede esperar. aceptar una cáscara diferente.Un intérprete alternativo, con el propósito de que los scripts de shell no interactivos normalmente sirven (como ocamlscript). Personalmente, no tengo ningún problema para evitar los scripts de shell para este propósito. Lo hago porque los scripts de shell son generalmente más difíciles de mantener (por ejemplo, sensibles a ciertos caracteres y manipulación de cosas mutables como 'comandos') y más difíciles de diseñar al mismo nivel de funcionalidad que los populares lenguajes de programación de propósito general podrían ofrecer (para ejemplo, comparar Bash a Python en este sentido).Sin embargo, hay casos en los que se necesita un script de shell nativo, por ejemplo, un archivo de perfil de shell que se obtiene de un shell cuando se inicia.Fondo

Aplicaciones prácticas

Algunos de ustedes pueden dudar de la utilidad práctica de lo que describo. Una aplicación práctica de esto es definir un perfil de shell en función de varias condiciones (por ejemplo, la plataforma del sistema / sistema operativo en el que se obtiene el perfil, lo que sigue de la política de seguridad, el shell concreto, el tipo de inicio de sesión / no de inicio de sesión del shell, tipo de shell interactivo / no interactivo). La ventaja sobre un perfil de shell genérico (bien diseñado) como un script de shell sería una mejora en el rendimiento (código de máquina nativo que puede generar un código fuente comprimido / optimizado en lugar de la interpretación del script escrito por el hombre), robustez (verificación de tipos, manejo de excepciones) , tiempo de compilación, verificación de la funcionalidad, firma criptográfica del ejecutable binario resultante, capacidades (poca o ninguna dependencia de las herramientas CLI del usuario, no hay limitación para usar la funcionalidad mínima cubierta por las herramientas CLI de todas las plataformas posibles) y funcionalidad multiplataforma (en los estándares de práctica como la Especificación de UNIX Único solo significan mucho, y muchos conceptos de perfil de shell se transfieren a plataformas No Unix como Windows, con su PowerShell, también).

Detalles de implementación, cuestiones secundarias.

El programador debe poder controlar el grado de genérico del script de shell generado. Por ejemplo, podría ser que el ejecutable binario se ejecute cada vez y saque el código de perfil de shell que sea apropiado, o simplemente genere un archivo de script de shell fijo adaptado a las circunstancias de una ejecución. En este último caso, las ventajas enumeradas, en particular las de robustez (por ejemplo, el manejo de excepciones y la confianza en las herramientas de usuario) son mucho más limitadas.[ADICIONAL]Si el script de shell resultante se encuentra en algún tipo de script de shell universal (como genera GNU autoconf) o script de shell nativo adaptado (dinámicamente o no) a un shell específico no es una pregunta principal para mí.fácil *: Me parece que esto se puede lograr básicamente al tener funciones disponibles en una biblioteca para los elementos de shell básicos. Dicha función simplemente se convertiría a sí misma más los argumentos pasados ​​en una declaración de script de shell semánticamente apropiada y sintácticamente correcta (como una cadena).

¡Gracias por cualquier comentario adicional, y especialmente por sugerencias concretas!