Melhores práticas para criar um Shell Script em GNU / Linux

Normalmente, quando você começa a trabalhar no Área de administração de servidores com sistemas operacionais GNU / Linux e / ou Unix, encontra-se (rostos) trabalhando em um ambiente onde geralmente há um monte de tarefas agendadas que outros administradores escreveram e que em algum ponto devemos gerenciar (administrar) para resolver qualquer problema, melhorar e / ou eliminar, para atender a uma nova exigência da Instituição onde trabalha. Portanto, não é de admirar que qualquer novo Sysadmin Em qualquer local de trabalho, você se depara com a difícil tarefa de compreender alguns dos Script shell criado por outros SysAdmin antigo, que não são bem escritos, ou estão em uma estrutura lógica ou de escrita, não são fáceis de entender, ou no pior dos casos, com comandos de comando, atípicos, antigos, ineficientes, ou escritos de uma forma estranha e confusa.

Shell Scripting

Enquanto resolvendo scripts mal escritos é sempre um aborrecimento momentâneo, isso ensina qualquer pessoa bom SysAdmin algo importante. Se alguém vai criar um Script shell para ser usado além de hoje, é sempre melhor escreva-os de uma forma muito profissional e padronizada, de modo que com o tempo, qualquer outra pessoa, ou a si mesmo, possa com o mínimo esforço e conhecimento alcançam compreensão e administração em um mínimo de tempo.

Portanto, após a série prática de publicações sobre "Aprenda Shell Scripting" onde examinamos alguns scripts muito práticos com comandos simples e básicos, começaremos com esta nova série chamada "Melhores práticas para criar um Shell Script em GNU / Linux", onde focaremos minuciosamente cada pequeno aspecto dele e o motivo de tantas coisas, ou seja, cobriremos algumas dicas que nos farão fazer scripts melhores, mas não tanto para nós mesmos, mas para a próxima pessoa (SysAdmin) que tem que gerenciá-los. Assim, você não precisa passar pela tarefa tediosa e difícil de descobrir o que eu codifico, como e por que e por que não funciona mais.

Neste primeira (1ª) postagem desta nova série "Melhores práticas para um bom Shell Script para GNU / Linux" Vamos conversar sobre o que vai ou deve ir no Cabeçalho do Shell Script.

=======================================
HEADER - INVOCATION OF THE SHELL
=======================================

#! / caminho / interpretar [argumento-parâmetro]

A linha superior é a estrutura básica com a qual um Shell Script para GNU / Linux é invocado. Seus elementos podem ser descritos da seguinte forma:

#! => sha-bang

O sha-bang (#!) no topo do Script criado ou a ser criado está um script que informa ao nosso sistema operacional que nosso arquivo é um conjunto de comandos que serão alimentados (serão interpretados) pelo interpretador de comandos indicado depois dele. O par de personagens #! na verdade, é um número mágico dois bytes, um marcador especial que designar um tipo de arquivo, e no nosso caso, um script de shell executável. Imediatamente após o sha-bang vem o nome de o caminho onde se encontra o intérprete a ser executado mais o nome do referido intérprete. Em outras palavras, este é o caminho para o programa que interpreta os comandos no script, seja um interpretador, uma linguagem de programação ou um utilitário. Esse shell então executa os comandos no script, começando no topo (a linha após o sha-bang) e ignorando quaisquer comentários. Alguns sha bang pode ser:

# / Bin / sh
#! / Bin / bash
#! / usr / bin / perl
#! / usr / bin / tcl
#! / bin / sed -f
#! / usr / awk -f

Cada uma das linhas descritas acima (como exemplo) invoca um shell diferente. A linha / Bin / sh, invoque o concha por padrão (Bash em um sistema operacional GNU / Linux) ou outro semelhante. Usando # / Bin / sh, o valor padrão de Bourne shell Na maioria das variantes comerciais de sistemas operacionais baseados em UNIX, isso torna o script criado portátil para outros sistemas operacionais que não são Linux adequadamente, mas semelhante ou baseado nele ou UNIX, embora isso sacrifique características específicas do BASH. No entanto, a sequência "#! / Bin / sh" está em conformidade com a norma POSIX sh standard.

tenha em conta que o caminho dado no sha-bang deve ser correto, caso contrário, uma mensagem de erro, geralmente "Comando não encontrado", será o único resultado da execução do script. Lembre-se do par de personagens »#! « pode ser omitido se o Script consistir apenas em um conjunto de comandos genéricos do sistema operacional, ou seja, sem usar diretivas internas do Shell. E tenha em mente mais uma vez que »#! / Bin / sh« invoca o interpretador de shell padrão, cujo padrão é »#! / Bin / bash« em uma equipe com ele Sistema operacional GNU / Linux.

Em relação aos argumentos, existem vários que poderiam ser utilizados, mas o mais comum é: »-E«. o que torna o script validar os erros de execução de qualquer comandoo (linha de execução) e se positivo, força a parada e saída, um típico é »-F« para indique qual script carregar e um dos mais raros é »-Rm« que executa a exclusão dele uma vez que sua execução seja finalizada. Só é possível especificar no sha bang até um argumento único (parâmetro) após o nome do programa a ser executado.

E finalmente, diga o roteiro as variáveis ​​globais que você usará nas partes essenciais do seu código, para validação de eventos, como caminho de execução, usuário autorizado, nome do script, entre outros. E terminar com o dados do programa, criador, organização, entre outros, além do licenciamento que se aplica ao programa.

Meu conselho (melhores práticas) escolher o melhor sha-bang e dirigindo um Script shell são:

#! / usr / bin / env bash

Por que usar o comando »Env« Indicamos ao Sistema Operacional o intérprete a ser utilizado com o caminho exato especificado por padrão, o que nos permite ter sha bang que aumenta a portabilidade dele, porque nem em todos OS GNU / Linux intérpretes ou programas têm o mesmo caminho. E sem argumentos, porque é melhor usar o comando conjuntoporque com ele podemos validar erros, gerais (-e) ou específicos (+ x / -x), Ó parágrafo limpar predefinições globais para variáveis ​​de ambiente (-i) ou específicas (-u / –unset). E finalmente, para executar ações específicas (- o) complementares dentro do script.

Portanto, meu HEADER recomendado seria:

#! / usr / bin / env bash
# Indica o interpretador bash com caminho absoluto por sistema operacional.

set -o errexit
# Para dizer ao script para parar e fechar quando um comando ou linha de execução falhar.

set -o substantivo
# Para dizer ao script para parar e fechar quando o script tenta usar variáveis ​​não declaradas.

set -o pipefail
# Para obter o status de saída do último pedido que retornou um código de saída diferente de zero.

#set -o xtrace
# Para rastrear o que está funcionando. Útil para depuração. Ative-o para verificar apenas erros.

Lembre-se de seguir também estas recomendações:

01.- Identifique seu código: Tornar seu código legível é muito importante e é algo que muitas pessoas também parecem esquecer. Tente fazer as indentações necessárias para perceber uma boa estrutura lógica à vista.

02.- Adicione espaços de separação entre as seções do código: Isso pode ajudar a tornar o código muito mais compreensível, já que o espaçamento por módulos ou seções ajuda a tornar o código legível e fácil de entender.

03.- Comente o máximo possível sobre o código: Na parte superior (ou inferior) de cada Ordem de Comando (Linha de Execução) ou Seção de Código, é ideal adicionar uma descrição da função do (s) script (s) para explicar o que acontece dentro do próprio código.

04.- Crie variáveis ​​com nomes descritivos de suas funções: Atribua nomes de variáveis ​​descritivas que obviamente identificam a função para a qual ela será criada. Embora você crie variáveis ​​temporárias que nunca serão usadas fora de um único bloco de código, ainda é bom colocar um nome que explique implicitamente (objetivamente) quais valores ou funções ele trata.

05.- Use a sintaxe VARIABLE = $ (command) para a substituição do comando: Se você deseja criar uma variável cujo valor é derivado de outro comando, existem duas maneiras de fazer isso no bash. Com carrapato de volta, isto é, com os personagens `` , Exemplo: VARIABLE = `parâmetros de opções de comando`, mas já está obsoleto, então a sintaxe VARIABLE = $ (comando) é a forma mais moderna, aceita e recomendada. NÃO -> DATA = `data +% F` / SIM -> DATA = $ (data +% F)

06.- Utilizar módulos e / ou variáveis ​​de Validação de Superusuário e Usuário Autorizado com ou sem senha: Para aumentar os níveis de segurança, se necessário.

07.- Utilizar módulos e / ou variáveis ​​de Validação do Sistema Operacional (Distro, Versão, Arquitetura): para evitar o uso em plataformas inadequadas.

08.- Utilizar módulos (procedimentos / seções) para confirmar a execução de ações críticas ou batch (módulos / funções): Para minimizar erros por improvisação ou descuido.

09.- Fornece interfaces amigáveis ​​ao usuário (amigável): Por Terminal com menus e cores com diálogo e com Interfaces gráficas para usuários básicos com Zenity, Gxmessage. E se possível use o suporte de alertas sônicos identificando eventos reconhecíveis de acordo com o som. Tentei o máximo possível para que seu script pudesse funcionam dos dois modos apenas habilitando e desabilitando opções / módulos / funções.

10.- Inclui os módulos (mensagens) Boas-vindas e Despedida: se necessário para aumentar a interatividade com o usuário.

11.- Inclui um módulo de verificação de dupla execução: Crie um arquivo de bloqueio para evitar que seja executado mais de 1 vez ao mesmo tempo.

12.- Racionalize o tamanho do script com funções e / ou módulos externos: Se o script for muito grande, divida o código usando funções ou divida-os em pequenos scripts que são invocados por meio de um principal.

13.- Invocação de forma clara e evidente as chamadas a outros Intérpretes (linguagens de programação) dentro do Script: Convide-os claramente por linhas ou módulos.

Exemplo:

# ================================================== #
#!/bin/bash
#Llamando a un interprete externo a BASH
echo 'El siguiente texto será mostrado por el interprete de PERL'
perl -e 'print "Este texto es mostrado por un script PERL embebido.\n";'
exit 0
# ==================================================#
# ==================================================# 
#!/bin/bash #Llamando al interprete de Python. 
echo 'El siguiente es un script de python:'
echo print "Hola, mundo!" | tee $HOME/.testpythonbash.py
python $HOME/.testpythonbash.py exit 0
# ==================================================#

# ======================================================= #
#!/bin/bash
# bash-y-perl.sh

echo "Saludos desde la parte BASH del script."
# Es posible añadir mas comandos BASH aqui.

exit 0
# Fin de la parte BASH del script.

###########################################################

#!/usr/bin/perl
# Esta parte del script se invoca con la opcion -x.

print "Saludos desde la parte PERL del script.\n";
# Podemos añadir mas comandos PERL aqui.

# Fin de la parte PERL del script.
# ======================================================= #
 

Em publicações futuras, expandiremos com mais detalhes cada uma das práticas descritas acima.

E se conhece outras boas práticas próprias ou de terceiros, não hesite em comentá-las para fazer um compêndio mais completo!

Até a próxima publicação desta nova série.


6 comentários, deixe o seu

Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: Miguel Ángel Gatón
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.

  1.   Max j ​​rodriguez dito

    Só um detalhe, é "shebang" 😛
    postagem muito boa, boas práticas no longo prazo sempre ajudam a padronizar.

  2.   Um que passou por aqui dito

    O Bash não é o shell padrão em todas as distribuições e, portanto, o link simbólico / bin / sh nem sempre aponta para o bash. No Debian, por exemplo (e suponho, portanto, Ubuntu):
    $ ls -l / bin / sh
    lrwxrwxrwx 1 root root 4 aza 8 2014 / bin / sh -> dash
    O shell padrão, portanto, no Debian é o dash. Veja aqui: https://wiki.debian.org/Shell

  3.   sem nome dito

    Como dica para conhecer o Shell em Uso:

    echo $ 0
    echo $ SHELL
    enviar | grep SHELL

  4.   Eng. José Albert dito

    Você realmente está certo! Experimentei o DEBIAN 9 e o Kali Linux 2.0 e é verdade! leva você para correr. Ainda mais a recomendação de: #! / Usr / bin / env bash se for o Shell que você deseja usar.

    E você está absolutamente certo, é shebang, mas em alguns sites (literaturas técnicas) eles chamam de shabang ou outras palavras, daí a minha confusão. Exemplo:

    Na computação, um shebang é a sequência de caracteres que consiste nos caracteres sinal numérico e ponto de exclamação (#!) No início de um script. Também é chamado de sha-bang, [1] [2] hashbang, [3] [4] pound-bang [5] ou hash-pling

    De: https://en.wikipedia.org/wiki/Shebang_%28Unix%29

    Y Capítulo 2. Começando com um Sha-Bang
    De: http://www.tldp.org/LDP/abs/html/sha-bang.html

  5.   Eng. José Albert dito

    Também: nome de base $ 0