Por Que Abandonei o WSL pelo MINGW64 — E a História do .bashrc

Por anos, o Windows Subsystem for Linux (WSL) tem sido a solução preferida para muitos usuários Windows que querem uma experiência de shell Linux. Mas para mim? O WSL nunca foi a escolha ideal.

Por Que Não WSL?

Eu não desgosto do WSL porque ele “não é Linux o suficiente” — ele é bastante robusto para muitas tarefas. Meu principal problema é que eu quero usar o ambiente de shell padrão com o qual estou confortável, sem fazer malabarismos com múltiplas distribuições ou lidar com algumas peculiaridades do WSL. Eu quero:

• Um gerenciador de pacotes direto
• Ferramentas como cygpath para integração perfeita com caminhos do Windows
• Integração fácil e nativa com meu ambiente Windows e ferramentas

Isso me levou a escolher o MINGW64, o ambiente MSYS2 que oferece um shell similar ao Unix com compatibilidade nativa do Windows. Ele vem com pacman como gerenciador de pacotes, inclui utilitários práticos como cygpath para converter caminhos do Windows para estilo Unix, e funciona suavemente com PowerShell e caminhos do Windows.

A Luta: Iniciando MINGW64 A Partir do PowerShell, No Diretório Correto

Eu queria uma função simples no PowerShell:

• Iniciar o bash do MINGW64
• Começar no diretório atual do PowerShell quando solicitado
• Manter meu prompt, funções e informações de branch do git funcionando perfeitamente

Mas não era tão fácil assim.

Os problemas que encontrei:

• Executar bash com --login -i sempre abria no $HOME independentemente do diretório atual.
• Usar exec bash dentro de -c para iniciar um shell novo resetava para home.
• Passar o diretório atual como argumento era complicado — bash não suportava a opção conveniente --cd.
• Executar shells aninhados dentro de -c fazia o diretório voltar para $HOME.
• Tentar contornar perfis com --noprofile --norc corrigia o diretório mas matava meu prompt e função de branch do git.

Tentei múltiplas variações, arquivos RC temporários, variáveis de ambiente, e até aceitei abrir uma nova janela de terminal — mas parecia desajeitado.

A Grande Revelação: Era Tudo Culpa do .bashrc

Depois de adicionar linhas de debug echo "Starting bash with PWD=$PWD" ao meu .bashrc, descobri o culpado:

cd $HOME

Essa única linha forçava todo novo shell interativo a começar no diretório home, sobrescrevendo qualquer diretório herdado do shell pai.

Ao comentar essa linha, finalmente tive uma função PowerShell funcionando que:

• Inicia o bash do MINGW64 como um shell interativo de login
• Começa no diretório atual do PowerShell quando solicitado
• Mantém meu prompt, informações de branch do git e funções personalizadas funcionando

A Lição: Sempre Olhe o Quadro Geral

É fácil perseguir hacks elaborados e soluções alternativas quando algo se comporta de forma inesperada. Mas às vezes, a causa raiz é uma linha simples escondida em um arquivo de configuração.

Antes de reinventar a roda:

Inspecione seus arquivos de inicialização do shell cuidadosamente

Entenda o que cada linha faz, especialmente aquelas que mudam diretórios ou variáveis de ambiente

Teste com saídas de debug para ver o que seu shell realmente faz na inicialização

Essa jornada me lembrou de dar um passo atrás e olhar todo o ambiente ao invés de apenas os sintomas. E agora, com MINGW64 e PowerShell funcionando suavemente juntos, estou de volta ao controle da minha experiência de shell no Windows.

Boa exploração!