Não use bash para scripts (o tempo todo)

bash logo

Escrever scripts é uma forma de codificação que às vezes não podemos evitar e nem devemos temer. A ferramenta padrão para escrever scripts é Bash para ambientes UNIX e PowerShell para ambientes Windows. No post Don’t Use Bash for Scripting (All the Time), Niko Heikkilä explica quando é apropriado usar o Bash para scripts e quando não é. Abaixo segue um resumo do artigo.

O Lado Bom do Bash

O Bash esta instalado em todo o lugar, portanto vai ser uma ferramenta que você encontra disponível em todo ambiente (linux).

Quanso você precisa de de uma sequência de comandos para fazer um determinado serviço que vai se repetir com sequência é muito bom ter o bash para repetir estes comandos.

O Bash brilha para uma sequência de pequenos comandos. Fazer o deploy é um deste scripts.

NDT: Apesar de que eu tenho utilizado bastante o pipe e ferramentas como sed, grep, cut e awk , não sendo necessário nem se quer o bash.

O Lado Feio do Bash

Eu estou declarando isso em voz alta. A sintaxe do Bash é feia e tem uma curva de aprendizado íngreme. Graças a ferramentas modernas, muitos desenvolvedores não iniciam sua jornada de programação configurando ambientes UNIX com o Bash. Portanto, não devemos presumir que todos os novos desenvolvedores que contribuem para um projeto de software conhecem seu caminho em torno de scripts Bash complexos.

Um script melhor

Escrever bons scripts Bash leva anos de prática. Não é um caminho infrutífero se você optar por segui-lo, mas requer um conjunto especial de ferramentas e habilidades para gerar valor. Para não falhar com o Bash, há dois conselhos importantes a serem adotados.

O primeiro conselho é usar o modo estrito não oficial do Bash para evitar a depuração desnecessária. Consiste em duas linhas que fazem seu script se comportar da seguinte maneira:

  • O script sai imediatamente ao encontrar um erro (-e flag)
  • O script sai imediatamente ao encontrar uma variável indefinida (-u flag)
  • O script sai imediatamente quando uma ou mais chamadas em uma instrução canalizada falham (opção pipefail)
  • O separador de campo interno (IFS) é definido para aceitar novas linhas e guias, facilitando e tornando mais lógico o manuseio notório da matriz Bash

Script sem o bash

Vamos imaginar que você tenha escrito um script Bash razoavelmente complexo, abrangendo dezenas ou - no pior dos casos - centenas de linhas. Agora precisa ser refatorado por uma razão ou outra. Esta é uma excelente posição para largar o Bash!

Primeiro, identifique qual é a principal língua da sua base de código. Se é PHP, Python ou Javascript, você está com sorte. Eu não estou muito familiarizado com o Go ou o Rust, mas eu vi e usei algumas ótimas ferramentas de linha de comando escritas com elas, então devo dizer que você também está com sorte com elas.

Em seguida, você provavelmente tem uma linha shebang no topo do seu script que lê algo como #!/Bin/bash. Altere isso para por exemplo. #!/usr/bin/env node substituindo o node com seu interpretador de código desejado.

Você já deve saber como fazer seu script executável com as permissões corretas, usando ./script; ou apenas script se você colocá-lo em uma pasta incluída na variável de ambiente $PATH. A partir daqui, comece a converter o seu script linha por linha para um novo idioma, importando os módulos necessários onde for necessário. No final, seu script pode ficar mais longo, mas definitivamente será mais robusto e sustentável.

Ferramentas que podem ajudar:

Se sua lógica de negócios depende muito de linha de comando, não hesite em adotá-las em vez de Bash.

Para saber mais

Don’t Use Bash for Scripting (All the Time)