Quando usar o Bash e quando usar o Perl / Python / Ruby?

Question

Estamos fazendo todo o nosso script com o Bash até agora, mas estou começando a me sentir um pouco bobo sobre isso. Embora possamos fazer tudo o que queremos com o Bash (é bem poderoso), estou começando a me perguntar se não devemos usar uma linguagem de script adequada (no nosso caso, provavelmente Ruby).

Como você decide quando usar o Perl / Python / Ruby sobre Bash para um script? Eu não acho que um script de inicialização com Ruby faz sentido, mas que tal um script um pouco mais longo que adiciona contas de e-mail?

    

Answer 1

Dado um problema com o qual ambos podem lidar, você deverá usar o que mais lhe convier. Em última análise, há muitos pequenos detalhes, e apenas a experiência pode ensinar você a vê-los.

O Bash é uma linguagem de script de propósito geral, como Python, Ruby, Perl, mas cada um tem pontos strongs diferentes em relação aos demais. Perl se destaca na análise de texto, Python afirma ser o mais elegante do grupo, scripts Bash são excelentes em "piping stuff around", se você sabe o que eu quero dizer, e Ruby ... bem, Ruby é um pouco especial em muitos de maneiras.

No entanto, as diferenças entre eles só importam quando você tem uma boa quantidade de experiência em scripts. Eu sugiro que você escolha um idioma e o limite até passar para o próximo. Você pode fazer muito em um shell script, mais do que a maioria das pessoas admitiria. Qualquer idioma é tão difícil quanto você deseja. Depois de escrever algumas coisas, cada idioma é "fácil" para você.

Estar familiarizado com o shell compensa rapidamente se você mora no Linux, então talvez você queira começar com isso. Se você encontrar uma tarefa que é impossível ou impraticável para resolver em um shell script, use outra coisa.

Além disso, tenha em mente que aprender scripts de shell é muito simples. O verdadeiro poder dele está em outros programas, como awk, sed, tr, et al.

    

Answer 2

TL; DR - use bash apenas para instalar uma linguagem melhor (se ainda não estiver disponível), caso contrário você estará perdendo tempo humano precioso e irrecuperável. Se você não pode fazê-lo na linha de comando manualmente sem erros, não faça script com bash / shell.

Em 2015, considero o seguinte:

1. sobrecarga de memória

   • A sobrecarga de memória em tempo de execução do Ruby / Python comparada ao bash é pequena (por causa de bibliotecas compartilhadas), enquanto provavelmente não é possível manter um script bash não trivial (ou seja, um com > 100 linhas) - portanto, o uso da memória não é um fator

2. tempo de inicialização

   • A inicialização em Ruby / Python pode ser um pouco mais lenta, mas é provável que você não execute muitos processos Ruby / Python completos em um loop apertado 100 vezes por segundo (se tiver esses tipos de necessidades, bash / shell é muito sobrecarga de qualquer maneira e você provavelmente precisará cair para C / C ++)

3. desempenho

   • quase todos os processamentos de dados típicos serão mais rápidos em Ruby / Python - ou pelo menos comparáveis (ou, você precisa de C / C ++ / Haskel / OCaml / de qualquer forma)
   • o desempenho real / gargalo na execução (ou mesmo produtividade) quase nunca nunca será "uma falta de uso do bash / shell" (mesmo o Ubuntu comutando traço para inicialização mostra como o bash é realmente o problema - e um busybox é provavelmente o único caso de uso, porque é nada mais que 'bash' e 'vi' para escrever e executar código, e muitas vezes não há como adicionar / baixar ou armazenar qualquer outra coisa )
   • executar outros processos para executar o trabalho (como sed / awk / grep) é, na verdade, um valor mais lento que chamar um método em um objeto ativo na memória

4. produtividade

   • é muito fácil cometer erros no Bash / shell em comparação com o uso de métodos, parâmetros, variáveis e exceções "reais" em Ruby / Python
   • Agile é mainstream, enquanto Bash não tem suporte para isso (falta de recursos de testes unitários, bibliotecas, OO, modularidade, linting, introspecção, registro, metaprogramação; quase impossível refatorar sem quebrar alguma coisa)
   • muitas incompatibilidades com outras shells, pequenas variáveis de ambiente podem quebrar completamente um script (e algumas importantes ferramentas de desenvolvimento como Puppet ignoram linhas e passam ou reescrevem variáveis importantes da shell), enquanto o Ruby / Python tem uma definição bem definida Caminhos de migração relativamente suaves, mesmo para grandes alterações de versão
   • aprender um novo idioma leva uma fração do tempo gasto de forma alternativa depurando scripts de shell devido a problemas específicos do shell (principalmente nomes de variáveis, não booleanos, sem exceções, etc.)
   • até mesmo os scripts de inicialização são uma exceção ( especialmente porque podem falhar durante a inicialização do sistema ) e, dadas as recentes falhas de segurança do bash, talvez seja melhor usar C (com boas bibliotecas) - sim, C precisa de compilação, configuração, etc., mas até mesmo um script de shell simples pode precisar de um repositório, depois de um versionamento e depois de um empacotamento de qualquer maneira.
   • o que estiver disponível com sed / awk / grep provavelmente já está embutido em Ruby / Python - sem que seja uma dependência, ou "diferenças" entre versões dessas ferramentas em plataformas (e se funcionar em seu configuração)
5. segurança no emprego
   • qual é o objetivo de garantir um emprego que você não gosta? (a menos que você goste de passar todas essas horas difíceis de depurar, mas triviais para fazer bugs no shell script)

Acho que não há razão para usar o Bash / Shell se você tiver o Ruby / Python instalado.

E, provavelmente, instalar o Ruby / Python não precisa nem mesmo de um script bash (com exceção do busybox, algumas ferramentas do sistema dependem da presença do Python / Perl).

E toda vez que você escreve um script de shell, você está "praticando" fazendo exatamente isso - em vez de aprender algo mais poderoso / produtivo.

Por que as pessoas usam o Bash hoje em dia? Porque é um hábito terrível, difícil de quebrar. Um roteiro raramente é "terminado para sempre" depois dos primeiros minutos - não importa o quanto as pessoas tendam a pensar dessa maneira. Junto com a falácia "é o último bug neste script".

Conclusão: use bash / shell somente quando for absolutamente forçado para (como ~/.bashrc , busybox), porque é quase never "a ferramenta certa para o trabalho "hoje em dia.

    

Answer 3

Eu uso o bash quando meu foco principal é o manuseio de arquivos. Isso pode incluir mover, copiar e renomear arquivos, bem como usar arquivos como entrada para outros programas ou armazenar a saída de outros programas em arquivos. Eu raramente escrevo código bash que realmente examina o conteúdo de um arquivo ou gera a saída para gravar em um arquivo; Deixo isso para os outros programas (que eu posso escrever em Perl ou python) que eu inicio via bash.

Eu uso Perl e python quando meu foco principal é ler dados de arquivos, processar esses dados de alguma forma e gravar saída em arquivos. Se eu me encontrar usando (no Perl) o comando system , back ticks ou (em python) o módulo subprocess muito extensivamente, considero escrever o script no bash. Por outro lado, às vezes eu começo adicionando tanta funcionalidade a um script bash que, eventualmente, faz mais sentido reescrevê-lo em Perl / python do que lidar com o suporte limitado (por comparação) do bash para escopo variável, funções, estruturas de dados, etc. .

    

Answer 4

Eu gosto dos critérios definidos nesta postagem do blog .

• If there aren’t any arguments to pass in, it’s probably a shell script.
• If there isn’t much for control logic (besides a single loop or if/else) it’s probably a shell script.
• If the task is automation of command-line instructions it’s almost definitely a shell script.

    

Answer 5

Eu encontrei esta análise Perl versus Bash útil ...

link

Por conveniência, estou copiando um resumo do autor 1) quando bash é melhores descobertas e 2) quando perl é a melhor conclusão ...

Quando o Bash está melhor ...

• Job Failure
• Commands on Exit
• Processing Job Output Lines
• Here Documents
• File Equivalencies
• File Timestamp Comparisons
• Tilde Expansion

Quando o Perl é melhor ...

Perl still beats the crap out of bash for most applications. Reasons I might prefer Perl include (but are not limited to):

• It’s going to be faster. Mainly because I don’t actually have to start new processes for many of the things I want to do (basename and dirname being the most obvious examples, but generally cut, grep, sort, and wc can all be eliminated as well).
• String handling in bash is rudimentary at best, and the whole $IFS thing is super-clunky.
• Conditionals in shell scripts can be wonky.
• Quoting in shell scripts can be a nightmare.
• bash’s case statement leaves a lot to be desired beyond simple cases (NPI).
• Arrays in bash suck. Hashes in bash (assuming your bash is new enough to have them at all) suck even harder.
• Once processing files or command output goes beyond the simple case I listed above, Perl starts really smoking bash.
• CPAN.

So it’s not like bash is going to take over for Perl any time soon. But I still find, after all these years, that many times a simple shell script can sometimes be simpler than a simple Perl script. As I say, I welcome all attempts to convince me otherwise. But, then again, there’s nothing wrong with having a few different tools in your toolbox.

    

Answer 6

Na minha experiência, bash versus python é uma troca entre tempo de desenvolvimento e flexibilidade. Uma solução rudimentar para um problema geralmente pode ser estabelecida em um script bash mais rapidamente do que pode ser em um script python.

O Python tenderá a fazer você pensar mais sobre a estrutura da sua solução do que o script bash equivalente. O Python tem mais poder expressivo do que um script bash e, portanto, tende a escalar e modificar melhor ao longo do tempo. Ele também permanece mais legível em geral.

O Bash está mais próximo do sistema de arquivos e pode ser ótimo para as primeiras soluções de rascunho para problemas que NÃO estão bem definidos. Por esse motivo, um script bash pode ser uma boa primeira opção para prototipar algo com a intenção completa de portá-lo para python, uma vez que o problema seja melhor compreendido.

    

Answer 7

O Bash é um shell Unix que inclui uma linguagem de script. É um processador de comando. você controla a maneira como você executa comandos, você os executa.

Perl / Ruby / Python são linguagens de propósito geral.

Quando você quer um script de shell, você usa o Bash

Se você deseja uma tarefa mais complexa ou não relacionada ao shell. Use Python, etc.

Eu nunca compararia essas linguagens na verdade. Python etc. são portáteis. Você pode executá-los em qualquer lugar. Bash é apenas para Unix.

O Python, etc., tem toneladas de bibliotecas reutilizáveis que resolvem milhões de tarefas.

É quase o mesmo se você perguntar. "Quando usar o Paint e quando usar o Photoshop"

Para o processamento de e-mails, eu usaria o Ruby novamente, porque ele tem muitas bibliotecas reutilizáveis.

Mas a melhor maneira seria combinar bash e ruby. Isso seria certo. Como você cria um script de processamento de e-mail no script ruby e bash, invocaria esse script ruby e executaria outros commans ds.

Então, sempre que você precisar de um processador de comandos, use o bash. Você executa comandos unix e os controla.

    

Answer 8

Artigo altamente tendencioso.

Eu não acho que o bash seja tão difícil de depurar. O Python geralmente é muito rígido, enquanto o bash permite que você seja muito criativo. Se você é um bom pensador inovador, vai gostar de bash.

Eu executo scripts bash em milhões de sequenciamento de DNA em milhares de arquivos, e isso me serve muito bem. E, ao contrário do que todos dizem, as mesmas versões dos scripts em C ++ não são executadas muito mais rapidamente (em poucos minutos, separá-las).

Eu acho que o bash, como o perl, não é o mais amigável / fácil de ler. Isso assusta as pessoas porque a maioria das pessoas não são grandes pensadores abstratos. Mas programadores mais brilhantes e mais criativos tendem a amá-lo e fazer uso freqüente dele. Se você conhece a si mesmo e sabe que tem um cérebro, não se assuste com isso. Se você é um pensador básico, talvez se apegue a algo como o Python. Para cada um deles.

    

Answer 9

Do "Livro de Lhama",

• Randal L. Schwartz, Tom Phoenix e Brian Foy, Perl de Aprendizagem (Sebastopol, CA: O'Reilly, 2011), ch. 1.2 "O que significa Perl?" , §§ "Por que Larry [o criador de Perl] apenas usou outro idioma?", P. 5:

Perl tries to fill the gap between low-level programming (such as in C or C++ or assembly) and high-level programming (such as “shell” programming [e.g., bash]). Low-level programming is usually hard to write and ugly, but fast and unlimited; it’s hard to beat the speed of a well-written low-level program on a given machine. And there’s not much you can’t do there. High-level programming, at the other extreme, tends to be slow, hard, ugly, and limited; there are many things you can’t do at all with the shell or batch programming if there’s no command on your system that provides the needed functionality. Perl is easy, nearly unlimited, mostly fast, and kind of ugly.

    

Answer 10

Shell scripts como bash, ksh, zsh, sh e fish são notoriamente surpreendentes, em comparação com linguagens de propósito geral de alto nível como Ruby, Python ou Perl. Enquanto um script de shell pode começar sua vida como um arquivo menor que o script de propósito geral equivalente, as surpresas levam a muitos códigos defensivos, como set -euo pipefail para habilitar modos estritos.

Para exampmle, a maioria dos idiomas shell continua executando linhas em um shell script, mesmo quando um dos comandos falha. Por outro lado, uma linguagem de propósito geral falha imediatamente no primeiro erro e, freqüentemente, de forma carregada, resultando em um comportamento mais seguro e previsível em scripts de complexidade leve.