Pessoal tudo bem com vocês? Sou iniciante programação, atualmente faço automação de microatividades usando a linguagem Python. Também, estou me habituando no mundo DevOps, foi Daí que me despertou a curiosidade de conhecer mais sobre Shell Script, poderiam me trazer alguns exemplos de quando uma automação com Shell Script se faz util em escala de usuario comum e a nivel profissional?
2 curtidas
Se quiser um material estilo “curso”, sugiro o BashGuide do Wooledge, que além de ensinar o básico, possui um excelente apêndice para usuários intermediários e avançados (o BashPitfalls) que explica comportamentos contraintuitivos do shell.
Para exemplos práticos, temos um tanto de tópicos nesse sentido, basta buscar “alias” e “funções”:
4 curtidas
Um exemplo é o kernel Linux, ele é lotado de shells.
Outro exemplo é o seu sistema operacional, rode o comando:
find / -name "*.sh" 2>/dev/null
Onde vc vai obter uma lista enorme de automações em shell que seu GNU/Linux usa.
4 curtidas
O Linux, de maneira geral, depende de shell script pra funcionar. Ou seria, pra existir? 
3 curtidas
Salve Emerson… Bons dias pra você!
Amo shell script, de verdade…
O melhor que voce pode fazer por voce é adquirir este livro:
Vale a pena demais amigo!
4 curtidas
Livro muito bom, só que ele da dicas de como vc pode tornar os seus scripts mais profissional, ou seja, ele não ensina a programar em shell, o conhecimento de programação de shell é um requisito para este livro.
4 curtidas
Depende do que cada um considera “útil” – e do que cada um considera um “usuário comum”. 
Como eu uso várias distros Linux em dualboot / multiboot – para observar e aprender, pero sin perder la diversión, jamás! – acabei criando alguns scripts para sair do “achômetro”, e obter informações objetivas (e com as datas exatas):
Será isso “útil”? – Há controvérsia!
Será isso “comum”? – Não. Eu diria que é bizarro, incomum. – Mas não impede que eu continue sendo um “usuário comum”, pois não sou “TI”, nem “usuário avançado”. Sou apenas um “usuário médio”, leigo em tecnologia.
Tanto é verdade, que meus scripts são toscos, primitivos. – Procuro “resultados”, sem gastar 5 anos fazendo pós-graduação. – Meus scripts não têm nenhuma “elegância”.
Comecei a mexer com isso, quando o Conky alterou bruscamente seu cálculo de “uso de Memória RAM” – e em seguida, outras ferramentas (screenFetch, Neofetch, inxi, htop, free / top), também começaram a mudar, cada uma num tempo diferente – e tornou-se impossível comparar os números que eu tinha guardado, de 2017, 2019 etc., com os números de Agosto 2020, e de 2021 em diante.
Isso, dentro de uma mesma distro! – Pior ainda, entre distros que tinham versões diferentes do Conky – cada uma, com um “cálculo” diferente do “uso de Memória RAM”.
Como comparar?
Criei um script para fazer esse “cálculo novo” (indicado por Linux Torvalds) – e salvar num arquivo TXT – para ser lido e exibido pelo Conky.
MEM_TOTAL=$(awk '/MemTotal/ { printf $2 }' /proc/meminfo); \
MEM_AVAIL=$(awk '/MemAvailable/ { printf $2 }' /proc/meminfo); \
MEM_USED_KILO="$(($MEM_TOTAL-$MEM_AVAIL))"; \
echo "$(($MEM_USED_KILO/1024))" MiB > MemInfo.txt
(Dá pra ver que me preocupei mais com a exatidão, do que com a elegância do script – e deixei de lado qualquer tentativa de converter MiB em GiB (ou vice-versa). – Cada um que faça suas contas de cabeça, ha ha).
E aproveitei para “monitorar” os cálculos diferentes (“antigo”, e “muito antigo”), que ainda eram usados por outras ferramentas… em versões diferentes, conforme cada distro, em diferentes momentos ao longo do tempo:
No KDE Plasma, também havia um abismo enorme, entre os números indicados pelo antigo KSysguard – e o novo “plasma-systemmonitor”:
Fiz alguns quadros, acompanhando a evolução de cada ferramenta (diferentes versões) – e a “involução” do htop, que avançou, depois recuou – em vários momentos, ao longo desses anos:
É claro que seria muito chato, ficar olhando capturas de tela, e digitando números (e cometendo erros de digitação). Além disso, a captura de tela não é “exata”. Às vezes, demoro 1 ou 2 segundos até apertar a tecla PrtScn. – Então, preparei outro script, que registra todos esses números, exatamente aos 5 minutos uptime. – Reinicio o PC, escolho uma distro, e vou tomar um cafezinho, ou lavar a louça, ou conversar com os cachórros – e o script registra os números daquela distro em um arquivo TXT, com a hora exata do boot:
Em seguida, outro script, que acrescenta as versões – de cada distro, Kernel, init, número de pacotes instalados, Plasma, Gimp, Chrome / Chromium, LibreOffice, Conky, free / top, htop, inxi, Fastfetch (ou screenFetch, Neofetch) etc. – e move o arquivo para outra pasta:
O resultado tem aparência “meio” confusa – inclusive, em algumas distros ainda não consegui isolar os números do htop (por falta de aha e html2text) – e o jeito é registrar uma sopa de letrinhas, para depois eliminar o excesso:
Fico, então, com vários arquivos, de um determinado momento (conforme o número de distro que tinha naquele momento) – e seria muito cansativo, abrir cada um, procurar determinado número, copiar, colar em outro arquivo. – Então, criei outro script, chamado “Summary.sh”, que extrai os dados para um arquivo “Summary.txt”:
Esse último script reúne cada informação, de todas as distros – e registra, embaixo, quantas distros forneceram aquela informação específica. – Isso é importante, pois ainda não consegui obter alguns números de todas as distros.
Neste caso – 8 distros regulares + 8 registros de uma nova distro – é importante saber quando o total foi 16 (ótimo!)… e quando não foi:
Isso me permite usar o recurso “bloco” do Kate / KWrite para emparelhar os nomes das distros ($ ls -1) e a hora exata de cada boot – e identificar cada momento, com as datas / horas (Kate / KWrite F7), nas minhas anotações – para saber o quê eu tinha feito, até aquele momento:
Também fica fácil copiar do TXT um bloco – e colar no LibreOffice Calc:
E já posso ilustrar – "como fiz para reduzir o uso de Memória RAM do Fedora 42 recém-instalado – até chegar perto do meu outro Fedora, que instalei em 2020, e vim fazendo upgrade até hoje:
Bom, você pediu “exemplos de scripts” – mas até aqui, me limitei a explicar “o quê” fiz – e o “porquê”.
Seria chato para você – e cansativo para mim – eu enfileirar um monte de scripts toscos, primitivos, que nem sei se vão lhe interessar.
Tenho feito anotações sobre tudo isso – e se tiver interesse, está lá:
4 curtidas
Você comentou sobre DevOps, é bem comum em integração e implantação contínua (CI/CD), mesmo que você use coisas como Circle CI ou GitHub Actions, facilita migrar para outro serviço no futuro, e torna mais fácil testar localmente o pipeline. Se você já é acostumado a fazer o seu fluxo de desenvolvimento todo no terminal.
Fica intuitivo gerar um script que vai fazer uma “receitinha de bolo”. Digamos que você criou um trigger para que, quando você fizer um merge do seu código no branch main do seu projeto esse workflow inicie:
- rode os seus testes automatizados
- se passarem, fazer backup do seu seu database via CLI da sua cloud
- aplique migrações no seu database se existirem
- suba o código do seu backend (a automação varia, por conteinrers de pé, etc)
- suba a versão web do seu frontend;
- gere bundles, assine e envie para as stores da Google e da Apple via fastlane, etc
Da para fazer em Python? Dá, mas esse tipo de automação de vários utilitários distintos, que lidam com aspectos da máquina do ambiente, rodam processos, builders, copiar arquivos, etc… ficam mais naturais em shell script, ao meu ver, pois fica muito próximo do fluxo do dia a dia no terminal.
5 curtidas
@Emerson_Moura pq vc não faz as automações em Python que é uma linguagem que vc já sabe?
O Python já vem instalado em todos os sistemas GNU/Linux.
E Python é mais popular em automações do que o shell.
O Python é mais poderoso que o Bash.
1 curtida
E pode combinar os dois tmb ne com os.system e subprocess ou chamar um script de shell separado ou chamar um script python de um shell script.
@frc_kde Excelente!! Muito obrigado pela contribuição.
1 curtida