Evolução do shell [duplicado]

Question

Eu tenho feito alguns scripts de shell.

Isso sempre me dá dor de cabeça. Claramente esta linguagem evoluiu organicamente, tanto quanto as linguagens da vida real; novas construções foram adicionadas dinamicamente, constantemente introduzindo novas regras e complexidades.

Aqui está um exemplo:

I understand that people like to avoid polluting the variable namespace; hence the function and the local part, which in turn forces the use of double quotes, which in turn forces the need to double up some but not all backslashes (and to know which ones -- oy!). I find that unnecessarily complicated. Granted, there's a tiny risk of collision if someone overrides BLUE or whatever, but on the other hand, the double-quote solution also carries the risk that a terminal will have backslashes in its escape sequences. And since the contents of the escape sequences are being parsed in the double-quote solution, but not in the single-quote solution, such a terminal could mess things up. Example of the difference:

taken from http://mywiki.wooledge.org/BashFAQ/053

É comum encontrar esse nível de complexidade em conversas técnicas sobre scripts de shell.

Existe também uma infinidade de diferentes camadas com sutis diferenças sintáticas.

Se um grupo de especialistas começou do zero, aposto que eles poderiam criar uma linguagem de script universal que fosse muito mais fácil de aprender, entender e programar.

Assim como um grupo de especialistas em C planejou C ++ ou C ++ - > C #

Existe um padrão ANSI C, mas existe algo semelhante para scripts de shell?

Será possível construir uma linguagem shell intermediária, que pode se expandir para vários shells?

Existe algum esforço nessa direção, ou estamos apenas presos a coisas do jeito que estão, como o teclado QWERTY?

    

Answer 1

Foram feitos esforços ao longo das linhas sugeridas por você:

• peixe - Amigável, Shell Interativo
• scsh - um shell Unix de código-fonte aberto dentro do Scheme (a linguagem de programação funcional lisp-syntax)
• es - outra programação funcional linguagem como um shell, com sua ramificação Xs .

o desenvolvimento de peixes parece estar em andamento. Eu não tentei pessoalmente nada disso, exceto es, e isso foi há muito tempo.

O problema com o esforço proposto é o objetivo: "mais fácil de aprender, entender e programar". Nenhum acordo real sobre "fácil de aprender" existe, e "fácil de entender" e "fácil de programar" pode estar em oposição a "fácil de aprender". A maioria das ferramentas do mundo físico não é fácil de aprender, mas anos de desenvolvimento foram investidos nelas e são muito poderosas.

Você pode ver a mesma tensão em muitas outras áreas: os editores de texto são notórios por serem (a) fáceis de aprender ou (b) úteis.

Mas o mundo do código aberto nos dá a oportunidade de usar o que queremos. A estonteante variedade de distros do Linux e o conjunto ainda mais estonteante de gerenciadores de janelas X11 mostram que talvez um modelo de tamanho único simplesmente não funcione e não precise.