Por que não deveria “apostar o futuro da empresa” em scripts de shell?[fechado]

Question

eu estava olhando http://tldp.org/LDP/abs/html/why-shell.html e foi atingido por:

Quando não usar scripts de shell

...

• Aplicações de missão crítica nas quais você aposta o futuro da empresa

Por que não?

Answer 1

Usar scripts de shell é bom quando você usa seus pontos fortes.Minha empresa possui alguns soft switches classe 5 e o código de processamento de chamadas e a interface de provisionamento são escritos em java.Todo o resto é escrito em KSH - dumps de banco de dados para backups, remoção, rotação de arquivos de log e todos os relatórios automatizados.Eu diria que todas essas funções de suporte, embora não diretamente relacionadas ao caminho de chamada, são de missão crítica.Especialmente a interação do banco de dados.Se algo desse errado com o código de interação do banco de dados e descartasse as tabelas de roteamento de chamadas, isso poderia nos tirar do mercado.

Mas nada dá errado, porque os scripts shell são a linguagem perfeita para coisas assim.Eles são pequenos, são bem compreendidos, manipular arquivos é seu ponto forte e são estáveis.Não é como se o KSH09 fosse uma reescrita completa porque alguém acha que ele deveria compilar para código de bytes, então é uma interface estável.Francamente, a interface de provisionamento escrita em Java fica instável com bastante frequência e os scripts de shell nunca falharam, pelo que me lembro.

Answer 2

Eu meio que acho que o artigo aponta uma lista muito boa de razões para não usar scripts de shell - com o único marcador de missão crítica que você aponta sendo mais uma conclusão baseada em todos os outros marcadores.

Dito isso, acho que o motivo pelo qual você não deseja criar um aplicativo de missão crítica em um script de shell é porque, mesmo que nenhum dos outros pontos se aplique hoje, qualquer aplicativo que for mantido por um período de tempo será evoluir a ponto de ser mordido por pelo menos uma dessas armadilhas potenciais em algum momento... e não há nada que você realmente possa fazer sobre isso sem que seja uma tarefa completa surgir com uma solução... desejando que você tenha usado algo com mais força industrial desde o início.

Answer 3

Obviamente, este é um espantalho para eu derrubar.Estou realmente interessado em saber por que as pessoas acreditam que os scripts de shell devem ser evitados em "aplicativos de missão crítica", mas não consigo pensar em um motivo convincente.

Por exemplo, vi (e escrevi) alguns scripts ksh que interagem com um banco de dados Oracle usando SQL*Plus.Infelizmente, o sistema não pôde ser dimensionado corretamente porque as consultas não usavam variáveis ​​de ligação.Ataque contra scripts de shell, certo?Errado.O problema não estava nos scripts de shell, mas no SQL*Plus.na verdade, o problema de desempenho desapareceu quando substituí o SQL*Plus por um script Perl que se conectava ao banco de dados e usava variáveis ​​de ligação.

Posso facilmente imaginar que colocar scripts de shell no software de vôo de uma nave espacial seria uma má ideia.Mas Java ou C++ podem ser escolhas igualmente ruins.A melhor escolha seria qualquer linguagem (assembly?) normalmente usada para esse propósito.

O fato é que, se você usa qualquer tipo de Unix, você está usando scripts de shell em situações de missão crítica, assumindo que você acha que a inicialização é de missão crítica.Quando um script precisa fazer algo em que o shell não é particularmente bom, você coloca essa parte em um subprograma.Você não joga fora o roteiro no atacado.

Answer 4

Scripts nada mais são do que programas de computador.Alguns argumentariam que os scripts são menos sofisticados.Essas mesmas pessoas geralmente admitem que você pode escrever códigos sofisticados em linguagens de script, mas que esses scripts não são mais scripts, mas programas completos, por definição.

Qualquer que seja.

A resposta correta, na minha opinião, é “depende”.O que, aliás, é a mesma resposta para a questão inversa de se você deve confiar em executáveis ​​compilados para aplicativos de missão crítica.

Um código bom é bom e um código ruim é ruim - seja ele escrito como um script Bash, um arquivo CMD do Windows, em Python, Ruby, Perl, Basic, Forth, Ada, Pascal, Common Lisp, Cobol ou C compilado.

Qual é não dizer que a escolha do idioma não importa. Há boas razões, às vezes, para escolher uma linguagem específica ou para compilar vs.interpretação (desempenho, escalabilidade, capacidade, segurança, etc.).Mas, sendo todas as coisas iguais, eu confiaria em um script de shell escrito por um grande programador em vez de um programa C++ equivalente escrito por um idiota em qualquer dia da semana.

Answer 5

Provavelmente são os shell scripts que ajudam a levar uma empresa em o futuro.Sei apenas do ponto de vista da programação que perderia muito tempo fazendo tarefas repetitivas que delegei a scripts de shell.Por exemplo, eu conheço a maioria dos comandos do Subversion para a linha de comando, mas se eu conseguir agrupar todos esses comandos em um script, posso disparar à vontade, economizando tempo e energia mental.

Como algumas outras pessoas disseram, a linguagem é um fator.Para minhas etapas curtas e programas de cola que não quero lembrar, confio completamente em meus scripts de shell e confio neles.Isso não significa que vou construir um site que execute bash no back-end, mas certamente usarei bash/ksh/python/qualquer coisa para me ajudar a gerar o projeto esqueleto e gerenciar meu empacotamento e implantação.

Answer 6

Quando leio esta citação, concentro-me no "formulários" em vez da parte de "missão crítica".

Eu li isso como se o bash não fosse para escrever aplicativos, mas sim para scripts.Então, claro, seu aplicativo pode ter alguns scripts de limpeza, mas não escreva critical-business-logic.sh porque outro idioma provavelmente é melhor para coisas assim.

Answer 7

Eu aposto que o autor está mostrando que está desconfortável com certos aspectos do script de shell de qualidade.Quem testa scripts BASH, por exemplo.

Além disso, os scripts estão fortemente acoplados ao sistema operacional subjacente, o que pode ser algo negativo.

Answer 8

Não importa, todos nós precisamos de uma ferramenta flexível para interagir com o sistema operacional.É uma interação legível por humanos com o sistema operacional que usamos, é como usar uma chave de fenda com os parafusos.A linha de comando sempre será uma ferramenta que precisamos de administrador, programador ou rede.Olhe para a janela que eles até expandiram em seu PowerShell.

Answer 9

Os scripts são inadequados para implementar certas funções de missão crítica, pois devem ter permissões +r e +x para funcionar.Os executáveis ​​precisam apenas ter +x.

O fato de um script ter +r significa que os usuários podem fazer uma cópia do script, editá-lo/subvertê-lo e executar sua versão editada do Cuckoo's-Egg.