Pergunta, tema de discussão

Estou muito interessado na geração de código-fonte de scripts de shell de linha de comando a partir de código escrito em uma linguagem compilada mais robusta, com bom desempenho e independente de plataforma (OCaml, por exemplo). Basicamente, você programaria em uma linguagem compilada para realizar quaisquer interações com o SO que você quisesse (eu proporia: as interações mais complexas ou aquelas que não são fáceis de fazer de maneira independente de plataforma), e finalmente você compilaria isto para um executável binário nativo (de preferência), o que geraria um script de shell que afeta no shell o que você programou na linguagem compilada. [ADICIONADO]: Com 'efeitos', quero definir as variáveis ​​de ambiente e opções de shell, executar certos comandos não padrão (o 'cola' de script padrão seria manipulado pelo executável compilado e seria mantido fora do script de shell gerado) e tal.

Eu não encontrei nenhuma solução desse tipo até agora. Parece ser relativamente fácil * perceber em comparação com outras possibilidades de hoje, como compilar o OCaml para JavaScript.

Já existem implementações (públicas) do que eu descrevo?Quais são as outras possibilidades que são (muito) semelhante ao que descrevo, e de que maneira eles diferem disso? (Compilação de linguagem para linguagem (de compilada para sh) vem à mente, embora isso pareça desnecessariamente difícil de perceber.)

O que eu façonão significar

Um shell alternativo (como o Scsh). Os sistemas que você administra nem sempre permitem que os shells sejam escolhidos pelo usuário ou por um administrador, e eu também espero que seja uma solução de administração do sistema exclusivamente para outros (clientes, colegas e outros), pessoas que não podem esperar aceite um shell diferente.Um intérprete alternativo, para o propósito que os shell scripts não interativos normalmente servem (como o ocamlscript). Pessoalmente, não tenho problema em evitar scripts de shell para esse propósito. Eu o faço porque shell scripts geralmente são mais difíceis de manter (por exemplo, sensíveis a certos caracteres e manipulação de coisas mutáveis ​​como 'comandos') e mais difíceis de criar com o mesmo nível de funcionalidade que linguagens de programação populares de propósito geral poderiam oferecer exemplo, compare o Bash com o Python a esse respeito).No entanto, há casos em que é necessário um script de shell nativo, por exemplo, um arquivo de perfil de shell originado por um shell quando é iniciado.fundo

Aplicações práticas

Alguns de vocês podem duvidar da utilidade prática do que eu descrevo. Uma aplicação prática disso é definir um perfil de shell com base em várias condições (por exemplo, a plataforma / SO do qual o perfil está sendo gerado, o que segue da política de segurança, shell de concreto, login / não-login do shell, interativo / não interativo tipo de shell). A vantagem sobre um perfil de shell genérico (bem trabalhado) como um script de shell seria melhoria no desempenho (código de máquina nativo que pode gerar um código-fonte compactado / otimizado em vez de interpretação de script escrito por humanos), robustez (verificação de tipo, manipulação de exceção , verificação de tempo de compilação de funcionalidade, assinatura criptográfica do executável binário resultante), recursos (menos ou nenhuma dependência de ferramentas CLI userland, nenhuma limitação para usar funcionalidade mínima coberta pelas ferramentas CLI de todas as plataformas possíveis) e funcionalidade de plataforma cruzada Os padrões de prática como a Especificação Única do UNIX significam apenas muito, e muitos conceitos de perfil de shell são transferidos para plataformas Non-Unix como o Windows, com seu PowerShell também).

Detalhes da implementação, problemas secundários

O programador deve ser capaz de controlar o grau de genericidade do script de shell gerado. Por exemplo, pode ser que o executável binário seja executado toda vez e coloque o código de perfil de shell apropriado, ou simplesmente gere um arquivo de script de shell fixo adaptado às circunstâncias de uma execução. No último caso, as vantagens listadas - em particular as de robustez (por exemplo, manipulação de exceções e dependência de ferramentas de usuários) são muito mais limitadas.[ADICIONADO]Se o script de shell resultante estaria em alguma forma de script de shell universal (como o GNU autoconf gera) ou script nativo de shell adaptado (dinamicamente ou não) para um shell específico não é uma questão primária para mim.easy *: Parece-me que isso pode ser realizado basicamente com funções disponíveis em uma biblioteca para as builtins básicas de shell. Tal função simplesmente se converteria mais os argumentos passados ​​para uma instrução shell script semanticamente apropriada e sintaticamente correta (como uma string).

Obrigado por qualquer outro pensamento e, especialmente, por sugestões concretas!