Tema: bash
-
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.
-
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.
-
Como impedir execuções simultâneas de um script administrativo: flock, lockf e mutex nomeado no Windows
Um script administrativo agendado ou disparado por um agente, que pode ser iniciado de novo antes de a execução anterior terminar, precisa de um lock e não de esperar que isso nunca aconteça. O flock(1) no Linux e o lockf(1) no FreeBSD associam um lock consultivo (advisory) do kernel a um processo em execução, por isso ele não fica obsoleto como um arquivo PID esquecido; no Windows, o equivalente é um System.Threading.Mutex nomeado.
-
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.
-
Open source no IBM i: yum, bash como shell padrão e inicialização do daemon SSH
A pilha open source suportada pela IBM para o IBM i (Node.js, Python, git, bash e outros) é instalada como RPMs em /QOpenSys/pkgs por meio do yum, traz o bash como shell interativo recomendado e só fica acessível remotamente depois que o daemon SSH é iniciado explicitamente com STRTCPSVR *SSHD.
-
Caminhos com espaços e caracteres especiais em bash, zsh, PowerShell e cmd
O mesmo nome de arquivo com espaço, curinga ou hífen inicial quebra um hábito de script diferente em cada shell: expansão sem aspas no bash ou zsh, -Path que interpreta curingas no PowerShell e argumento sem aspas no cmd. Cada shell tem sua própria saída para caminhos literais, e find/xargs precisam de separação por caractere nulo para funcionar bem juntos.
Legível por máquina: JSON