Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

--- boas_praticas_de_programacao_shell_script [2018/08/17 15:22] – /* Testes automatizados */ cartola
+++ boas_praticas_de_programacao_shell_script [2019/08/02 15:16] – [Frameworks] cartola
@@ Linha 1: / Linha 1: @@
+====== Programação Shell Script: boas práticas ======
+Antes veja [[ti_publica:desenvolvimento_de_sistemas:boas_praticas|Desenvolvimento de sistemas: boas práticas]]
 Esse é um guia pessoal de referência. Na maioria dos casos a dica se baseia no **Shell Bash**, mas muitas são genéricas. Anoto aqui dicas que considero úteis, de modo que possa acessá-las de qualquer lugar, aproveitando para compartilhar com quem possa ter interesse.
@@ Linha 5: / Linha 8: @@
 Naturalmente algumas dicas aqui provavelmente servirão pra outras linguagens de programação. A medida que eu perceber isso vou tentar marcá-las como "**DICA GERAL**"
+===== Referências Externas =====
+==== Gerais ====
+  * [[http://kvz.io/blog/2013/11/21/bash-best-practices/|Bash best practices]]
+==== Frameworks ====
+  * [[https://invent.life/project/bash-infinity-framework/|Infinity framework]]
+  * [[http://bashinator.org/|Bashinator]] - lista outros frameworks também
+  * [[https://github.com/sstephenson/bats]] - Testes unitários automatizados
 ======= Documentação =======
@@ Linha 41: / Linha 52: @@
 ======= Testes automatizados =======
-Existem linguagens que tem ferramentas pra facilitar isso, mas trabalhando com o conceito, é possível fazer pra qualquer linguagem. Como Bash trabalha com funções, o melhor é refatorar o código de modo que funções recebam e retornem valores ou que executem coisas verificáveis, viabilizando testes externos que não necessariamente precisem executar as tarefas reais ou no ambiente real.
+Existem linguagens que tem ferramentas pra facilitar isso, existe alias o [[https://github.com/bats-core/bats-core|BATS]] ([[https://hk.saowen.com/a/76a0859c6dbd6a2ac11c80dada4234fac367fdf43db39cf7e32992e46e8e1ed9|veja também esse guia]]) pro shell Bash, mas trabalhando com o conceito é possível fazer pra qualquer linguagem. Como Bash trabalha com funções, o melhor é refatorar o código de modo que funções recebam e retornem valores ou que executem coisas verificáveis, viabilizando testes externos que não necessariamente precisem executar as tarefas reais ou no ambiente real.
 Um script muitas vezes é pequeno e, nesses casos, a criação de testes talvez não se justifique. Se começar a crescer, se for complexo, se for ser alterado de tempos em tempos, então pode se considerar essa criação dos testes, que garantirá o funcionamento esperado de cada parte do código, evitando que uma eventual alteração faça com que se crie um bug. Essa é a moral da coisa.
@@ Linha 91: / Linha 102: @@
 Exemplo: definindo múltiplas variáveis
   read filesystem total used free perc name < <(df . | tail -1)
+===== Lendo linha a linha e atribuindo colunas a variáveis =====
+  echo "Sistema"
+  echo "  disponivel"
+  df | grep -v "^Filesystem" | while read fs total used avail perc mount; do
+    echo "$fs"
+    echo "        $avail"
+  done
+Resultado da execução:
+  $ ./exemplo.sh
+  Sistema
+          disponivel
+  /dev/mapper/system-root
+          2014976
+  devtmpfs
+          8121660
+  tmpfs
+          8133648
+  *  opção de delimitador
+  *  como jogar linha inteira numa variável
+  *  readarray