O til em seu PATH pode não ser sua HOME

Artigo original ↗ Discussão no Hacker News ↗

Usar `~` em comandos de shell — especialmente ao modificar o `PATH` — pode se comportar de forma muito diferente do que muitos usuários esperam, porque a expansão de til só ocorre em posições específicas sem aspas e varia entre shells POSIX e extensões de Bash/Zsh. Comentários compartilham armadilhas como inserir acidentalmente um `~` literal no `PATH` ou até apagar `$HOME`, debatem se diretórios locais do usuário devem preceder caminhos do sistema e contrastam as várias “armadilhas” do Bash com shells alternativos como fish, nushell e zsh. A discussão destaca como regras sutis de aspas e expansão, além de ferramentas e documentação inconsistentes, tornam o uso e a escrita de scripts em shell robustos mais difícil do que parece.

Expansão de til e comportamento do PATH

  • O til só se expande em posições específicas (no início de uma “palavra” sem aspas; em alguns shells também após dois-pontos sem aspas em atribuições).
  • Colocar aspas em ~ impede a expansão e pode deixar um ~ literal no PATH, que é o problema original.
  • Alguns shells (zsh, fish) oferecem maneiras mais convenientes ou baseadas em arrays para adicionar ~/.local/bin ao PATH, lidando corretamente com a expansão.
  • Vários comentaristas preferem usar $HOME em vez de ~ em scripts para evitar surpresas.

Regras de aspas e armadilhas comuns de shell

  • Entender mal quando usar aspas é uma grande fonte de bugs: as pessoas tanto colocam aspas demais quanto de menos.
  • Orientação oferecida:
    • Sempre coloque aspas em expansões de variáveis ("$var") em argumentos para evitar divisão por palavras e globbing.
    • Use aspas simples apenas para strings literais que contenham caracteres especiais.
  • Expansão de variáveis e expansão de til se comportam de forma diferente; tratá-las como iguais leva a erros.

Ordenação e segurança do PATH

  • Debate sobre se deve-se colocar no início ou no fim diretórios do usuário como ~/.local/bin.
    • Um lado: adicionar ao fim para que binários do sistema tenham precedência, reduzindo o risco de substituições maliciosas.
    • Outro lado: adicionar ao início para que os usuários possam substituir intencionalmente ferramentas do sistema desatualizadas.
  • Consenso de que, se um invasor consegue gravar nos diretórios do seu PATH, você já está em um comprometimento sério.

POSIX vs comportamento específico do shell

  • Alguns comportamentos no artigo dependem de extensões do bash/zsh e não são portáveis para /bin/sh (frequentemente dash ou ash).
  • Regras de expansão de til do POSIX foram citadas; houve confusão inicial, depois esclarecimento de que a expansão após : sem aspas em atribuições é permitida.
  • Vários lembretes para distinguir “bashisms” de construções estritamente compatíveis com POSIX.

Shells alternativos e escolhas de linguagem

  • Muitos criticam o bash como uma linguagem de script “terrível” ou frágil, com muitos casos-limite.
  • Alternativas mencionadas: fish, zsh, nushell, murex, PowerShell, Perl, Ruby, etc.
  • Contraponto: bash/sh continuam dominantes porque já vêm instalados em todo lugar, especialmente em sistemas remotos.

Nomes de arquivos, caracteres e robustez

  • Alguns argumentam que a vida seria mais fácil se os caminhos só permitissem um conjunto ASCII restrito, para evitar problemas de codificação e parsing.
  • Outros defendem fortemente suporte a scripts não latinos e Unicode arbitrário, apesar das dores de cabeça nas ferramentas.
  • Usar espaços ou - no início em nomes de arquivos é apontado como uma fonte frequente de bugs e armadilhas de segurança.

Ambiente, HOME e depuração

  • Foi observada a distinção entre $HOME e a home da conta nas bases de dados do sistema; eles podem divergir e confundir a resolução de ~.
  • Manipular HOME para testes pode entrar em conflito com ferramentas que resolvem diretórios pessoais de maneiras diferentes.
  • Grandes organizações costumam ter arquivos de inicialização do shell profundamente em camadas, dificultando rastrear onde as variáveis são definidas; ferramentas de tracing para inicialização do shell foram recomendadas.

Histórias de guerra e lições

  • Várias anedotas: criar um diretório literal ~, executar rm -r ~ por engano e ferramentas de IA criando diretórios ~.
  • Lições extraídas: evite rm -r quando possível, use caminhos mais explícitos (./~) e trate recursos de shell com cautela.