Qual é a vantagem do shell script sobre as linguagens de programação interpretadas? [fechadas]

(Não tenho certeza se é uma pergunta apropriada aqui)

Os scripts de shell, como os escritos bash, podem fazer muitas coisas. Eles podem chamar programas Unix, canalizar sua saída, redirecionar E / S de / para arquivos, controlar o fluxo, verificar se existe um arquivo etc.

Mas uma linguagem de programação moderna, por exemplo, pythone ruby, também pode fazer essas coisas. E eles são (eu acho) mais legíveis e fáceis de manter.

bashgoza de ampla adoção. Mas muitas distribuições instalaram o pythonintérprete também.

Então, qual é a vantagem de fazer shell de um script? Se eu pudesse escrever python, rubyou perl, vale a pena aprender bash?

Os shells possuem recursos especializados para trabalhar com arquivos e obter dados de um programa para outro (assumindo que os dados sejam texto). Para essas tarefas, os scripts de shell podem ser menos pesados ​​do que uma linguagem de script como o Python.

Os scripts de shell também têm a vantagem de que os comandos que você usa são basicamente os mesmos que você usaria na linha de comando - portanto, se você pode fazer algo no shell, está na metade do caminho para criar scripts para a mesma operação.

Aqui, por exemplo, está um script bash que move todos os arquivos PNG do diretório atual para um diretório especificado.

#!/usr/bin/sh
mv *.png $1

Aqui está uma versão do Python.

#!/usr/bin/python
import sys, shutil, glob
for filename in glob.iglob("./*.png"):
    shutil.move(filename, sys.argv[1])

Você notará:

• O script bash é um terço do Python, se você contar linhas (excluindo a linha shebang) - ainda menos pela contagem de caracteres
• O script Python requer que três bibliotecas sejam importadas, enquanto tudo o que você precisa para esta tarefa está disponível nativamente no bash
• O script Python requer um loop explícito para mover os arquivos, enquanto isso faz parte da semântica do mvcomando no bash
• O script bash pode ser executado mais rapidamente - você provavelmente o chamará do bash e poderá usá source-lo na mesma instância do shell
• glob.iglob("./*.png") é um bocado só para dizer *.png

Se você quisesse escrever uma operação básica de pipe em Python, ficaria surpreso com a verbosidade. (Obviamente, algumas coisas, como passar porgrep , podem ser substituídas pelo código Python, em vez de usar um programa externo, portanto, muitas vezes você não precisa canalizar tanto.)

Como um contra-exemplo, uma vez eu tive que escrever uma rotina que verificava quanto tempo cada um dos nomes de arquivos estava em um diretório específico. Se tivessem mais tempo do que o suporte de um sistema operacional específico, teriam que ser reduzidos. Isso poderia resultar em nomes de arquivos duplicados, que eu precisava corrigir, e, como seriam vinculados a partir de uma página da Web, os nomes abreviados precisariam permanecer estáveis, ou seja, deveriam ser gerados de forma que o mesmo nome de arquivo longo sempre resultasse em o mesmo nome de arquivo reduzido. Fiz isso gerando um md5 hexadecimal do nome do arquivo longo e anexando os quatro primeiros caracteres ao nome abreviado (os nomes ainda podem colidir, mas era muito pouco provável, então apenas verifiquei essa condição e paguei a taxa se isso acontecesse) .

Eu fiz isso no bash porque fazia parte do nosso sistema de compilação que já estava escrito no bash. Foi exatamente tão difícil de acertar como você provavelmente está pensando. Levaria muito menos tempo para escrever em Python e provavelmente teria sido mais claro também.

Em resumo: diferentes idiomas são projetados para diferentes tipos de tarefas; escolha o idioma disponível para você que melhor se adequa à tarefa em questão.

As respostas existentes também são válidas, mas há uma razão que ninguém mencionou ainda: porque estará lá.

Qualquer instalação * nix é feita com um conjunto de pacotes opcionais que podem ou não ser carregados, e nem todos os sistemas terão Python, Perl ou Ruby. Mas se é esperado que o sistema tenha alguma capacidade interativa, ele terá um shell. Isso significa que os scripts shell funcionarão em sistemas de servidores a desktops de programadores, desktops de thin client de secretariado a dispositivos incorporados, em qualquer sistema que suporte um sistema de arquivos gravável e uma linha de comando do bash.

Para alguém que só trabalha em um ambiente de servidor consistente, isso pode ser considerado um dado adquirido e não é tão importante. Para alguém que trabalha em um ambiente mais variado, isso não deve ser esquecido.

Uma parte significativa da sua pergunta é respondida aqui:

Por que as linguagens de script (por exemplo, Perl, Python, Ruby) não são adequadas como linguagens de shell?

Aqui está um trecho da minha resposta a essa pergunta :

Existem algumas diferenças em que consigo pensar; apenas pensamentos fluindo aqui, em nenhuma ordem específica:

1. Python & Co. foram projetados para serem bons em scripts. A Bash & Co. foi projetada para ser apenas boa em scripts, sem absolutamente nenhum compromisso. IOW: Python foi projetado para ser bom tanto em scripts quanto em não scripts, o Bash se preocupa apenas com scripts.

2. Bash & Co. não são digitados, Python & Co. são fortemente digitados, o que significa que o número 123, a string 123e o arquivo 123são bem diferentes. No entanto, eles não são digitados estaticamente , o que significa que precisam ter literais diferentes para eles, a fim de mantê-los separados. Exemplo:

   • Ruby: 123(número), Bash:123
   • Ruby: '123'(string), Bash:123
   • Ruby: /123/(regexp), Bash:123
   • Ruby: File.open('123')(arquivo), Bash:123
   • Ruby: IO.open('123')(descritor de arquivo), Bash:123
   • Ruby: URI.parse('123')(URI), Bash:123
   • Ruby: `123`(comando), Bash:123

3. Python & Co. são projetados para escalar até 10000, 100000, talvez até 1000000 programas de linha, Bash & Co. são projetados para escalonar até 10 programas de caracteres .

4. Na Bash & Co., arquivos, diretórios, descritores de arquivos, processos são todos objetos de primeira classe; no Python, apenas objetos Python são de primeira classe; se você deseja manipular arquivos, diretórios etc., precisa envolvê-los em um Objeto Python primeiro.

5. A programação do shell é basicamente a programação do fluxo de dados. Ninguém percebe isso, nem mesmo as pessoas que escrevem conchas, mas acontece que as conchas são muito boas nisso, e as linguagens de uso geral nem tanto. No mundo da programação de uso geral, o fluxo de dados parece ser visto principalmente como um modelo de concorrência, não tanto como um paradigma de programação.

Tenho a sensação de que tentar abordar esses pontos inserindo recursos ou DSLs em uma linguagem de programação de uso geral não funciona. Pelo menos, ainda estou para ver uma implementação convincente disso. Existe o RuSH (Ruby shell), que tenta implementar um shell no Ruby, existe o rush, que é um DSL interno para programação de shell no Ruby, o Hotwire, que é um shell Python, mas IMO nenhum deles chega nem perto para competir com Bash, Zsh, peixe e amigos.

Eu diria que um script de shell tem a vantagem em situações em que você apenas deseja criar uma tarefa automatizada super simples. Por exemplo, se você quiser escrever um script que faça backup de um diretório de um servidor para outro todos os dias às 5:00, seria um exagero usar uma linguagem de programação pesada.

Por outro lado, se sua tarefa de programação precisar mais de estruturas de controle (if / then / else), estruturas iterativas (loop), E / S de banco de dados e arquivo, etc., provavelmente será mais adequada para uma capacidade mais linguagem de programação que um script de shell.

Eu acho que uma boa regra geral é:

automatingSimpleTask ? shellScript() : programmingLanguage();

Embora você possa iniciar programas a partir de um programa python / ruby ​​/ qualquer que seja, é diferente no shell. Você pode precisar usar uma API para iniciar algo - fork () por exemplo. Em um script de shell, os programas se comportam mais como funções em uma linguagem de programação convencional e podem ser executados, canalizados, etc. com o mínimo de esforço. O fluxo de dados é muito claro também usando tubos.

Se você é totalmente livre para escolher a linguagem de programação usada para determinadas tarefas, provavelmente pode evitar completamente o aprendizado do bash e executar todas as tarefas de programação de scripts com Perl, Python ou Ruby. Às vezes, isso pode levar a uma solução mais detalhada, especialmente no caso em que você só precisa de um script que chame uma sequência de outras ferramentas Unix, mas, em casos mais complexos, você está certo, essas linguagens de script modernas oferecem a você mais possibilidades para escrever um código de melhor manutenção (eles também oferecem mais possibilidades de escrever código ofuscado, mas a escolha é sua).

Por outro lado, geralmente não somos livres para escolher o idioma que mais gostamos, porque temos que trabalhar com código legado ou código escrito por alguém que conheceu o bash, mas não conhecia uma das linguagens de script que você nomeou.

O script de shell é uma linguagem de programação interpretada. Aqui estão algumas razões pelas quais eu escolhi escrever scripts no bash em vez de perl, python ou alguma outra linguagem de script:

Funciona em qualquer lugar : intérpretes mais complexos nem sempre estão disponíveis, como durante a inicialização do sistema ou em sistemas embarcados. O Bash está disponível mesmo no busybox.

Funciona na linha de comando : se você é versado em scripts de shell, pode usar essas habilidades para executar tarefas complexas em scripts ad-hoc diretamente na linha de comando. Eu uso essa habilidade diariamente como administrador de sistemas.

É mais fácil escrever programas que chamam outros programas: se o que você está tentando fazer é encadear vários programas existentes de maneiras interessantes, pode ser mais fácil fazer isso em um shell script do que em uma linguagem de nível superior.

Se o programa tiver 30 linhas ou menos, normalmente o escreverei usando scripts de shell. Se houver alguma manipulação complexa ou complexa ou análise para lidar, farei isso usando python ou perl.

Você deve dar uma olhada no coffeescript. Suas palavras:

Por trás de todos esses aparelhos e ponto e vírgula, o JavaScript sempre teve um modelo de objeto maravilhoso em seu coração. O CoffeeScript é uma tentativa de expor as partes boas do JavaScript de uma maneira simples.

A regra de ouro do CoffeeScript é: "É apenas JavaScript".

Bem ... aqui vem a resposta super iniciante.

Como iniciante no aprendizado automático nos últimos 6 meses, e experimentando um pouco de C, C ++, Javascript e mais Bashscript nos últimos dias ... posso lhe dizer:

Os scripts de shell, como os escritos no bash, podem fazer muitas coisas. Eles podem chamar programas Unix, canalizar sua saída, redirecionar E / S de / para arquivos, controlar o fluxo, verificar se existe um arquivo etc.

e não é tão simples assim fantástico! ? loops e variáveis? Uau!

python e ruby, também podem fazer essas coisas. E eles são (eu acho) mais legíveis e fáceis de manter.

Por favor, me diga onde você vê isso? Escrevi bashscript no gedit mesmo no geany e posso formatar (tabs?) E li meu código na velocidade da luz usando o bashscript na comparação em outros idiomas.

Esses idiomas têm outras ferramentas para manter a ordem? Eu sei que orientado a objetos economiza MUITO código, mas ... as pessoas dizem que o bashscript também é OO! WOW 2! Esse é o meu ponto aqui. Indo a:

a vantagem de fazer shell de um script

está dentro desta pergunta: como fazer o que essa merda pode fazer em perl, phyton ou ruby? É fácil?

( bashdamnthing = xdotool )