Tema: scripting
-
Tratamento de erros em PowerShell para scripts de administração: erros terminantes, $ErrorActionPreference e $LASTEXITCODE
O PowerShell tem duas classes de erro com comportamentos distintos num script: erros terminantes, que o try/catch consegue interromper, e erros não terminantes, que só $ErrorActionPreference ou -ErrorAction podem transformar em interrupção. Uma terceira classe, as falhas de executáveis nativos, não segue nenhum desses caminhos, a menos que $PSNativeCommandUseErrorActionPreference esteja definido (PowerShell 7.4+, experimental na 7.3).
-
Como escrever um script POSIX sh portável entre Linux, BSD, macOS e AIX
Um script que deve rodar sem alterações no dash do Debian, no bash-como-sh de uma máquina Linux, no FreeBSD, no macOS e no AIX precisa ficar dentro da Shell Command Language do POSIX e evitar flags exclusivas do GNU; o checkbashisms e uma lista curta de diferenças entre comandos GNU e BSD pegam a maior parte do que quebra.
-
Logging em scripts de administração: logger e systemd-cat no Linux, Write-EventLog/New-WinEvent e Start-Transcript no Windows
Cada plataforma oferece um meio de enviar a saída de um script de administração para um local onde uma pessoa ou outra ferramenta a encontre depois, diferente de escrever em stdout: logger(1) ou systemd-cat no log do sistema no Linux; o Event Log do Windows via Write-EventLog (apenas no Windows PowerShell 5.1) ou New-WinEvent; e Start-Transcript para uma captura bruta da sessão. Nenhum deles deve jamais receber um segredo.
-
Dry-run e confirmação em scripts de administração: -WhatIf/-Confirm no PowerShell e uma flag --dry-run no shell
O PowerShell tem um mecanismo nativo, o SupportsShouldProcess, que dá a uma função própria os switches -WhatIf e -Confirm reais, ligados à mesma chamada $PSCmdlet.ShouldProcess() usada pelos cmdlets internos. Scripts de shell não têm um equivalente nativo, por isso uma flag --dry-run precisa ser propagada manualmente.
-
Como escrever scripts de administração idempotentes: verificar antes de alterar, arquivos drop-in e comentários marcadores
Um script de administração que um agente pode reexecutar após uma falha parcial ou por agendamento repetido deve deixar o sistema no mesmo estado, rodando uma ou cinco vezes. Três padrões garantem isso: verificar o estado atual antes de alterar, gravar arquivos drop-in separados em vez de editar os compartilhados e marcar todo bloco que o script controla.
-
Executar um comando como outro usuário a partir de um script: sudo -u, runuser, su -c e o -Credential do PowerShell
sudo -u, runuser e su -c executam um comando com outro ID de usuário e de grupo, mas diferem quanto à necessidade da senha do usuário de destino, ao carregamento de um ambiente de login e a quem pode invocá-los; o Start-Process e os cmdlets de remoting do PowerShell recebem um objeto -Credential, e nenhuma dessas ferramentas deve receber senha por pipe ou argumento de linha de comando.
-
zsh como shell padrão do macOS: o que quebra em um script escrito para bash
Desde o macOS 10.15, o zsh é o shell de login e interativo padrão do macOS. Um script que presume a divisão de palavras do bash, arrays começando em zero ou globbing tolerante pode se comportar de outro modo, ou falhar por completo, na sessão interativa zsh de um agente em um Mac, mesmo sem considerar a idade do próprio /bin/bash.
-
Usar o SMIT como gerador de comandos em vez de sistema de menus
Os menus do smit/smitty acabam por executar comandos comuns do AIX, e a ferramenta foi feita para mostrar quais: a janela de saída exibe o comando montado, e smit.log/smit.script registram cada comando e suas flags exatas, com data e hora. Ler o smit.script depois de uma tarefa feita pelos menus é uma forma rápida de descobrir o comando não interativo equivalente.
-
Armadilhas do cmd.exe e de scripts batch: momento de avaliação do %ERRORLEVEL%, expansão atrasada e escape com circunflexo
Arquivos batch ainda aparecem em instaladores, tarefas agendadas legadas e ferramentas de fornecedores. O %ERRORLEVEL% é expandido na análise da linha e pode trazer um valor desatualizado, a expansão atrasada muda esse comportamento, e o circunflexo é o caractere de escape que a maior parte do código batch gerado por agentes erra na primeira tentativa.
-
Códigos de saída como contrato entre scripts e o agente que os chama
Um agente que executa um script e decide o próximo passo pelo código de saída precisa que esse código tenha o significado das convenções do shell: 0 para sucesso, números positivos pequenos para as falhas definidas pelo próprio script, 126/127 para um comando que não pôde ser executado e 128+n para término por sinal. Além disso, precisa de pipefail ou PIPESTATUS para enxergar o código real através de um pipeline.
Legível por máquina: JSON