Coleção de ferramentas Linux modernas: novos CLIs que substituem comandos tradicionais

• Apresentação de várias ferramentas modernas de linha de comando que aumentam a eficiência do trabalho no Linux
• Inclui muitas ferramentas focadas em desempenho, desenvolvidas em Rust, Go e outras linguagens, que substituem de forma moderna os comandos Unix tradicionais ou ampliam suas funcionalidades

Ferramentas para visualização e navegação de arquivos

• bat : versão aprimorada do comando cat, com syntax highlighting e integração reforçada com git
• exa : visualizador moderno de arquivos que substitui ls/tree, mas atualmente está descontinuado
• eza : fork do exa, oferecendo um ls/tree moderno
• lsd : ls de próxima geração, com compatibilidade com o tradicional e saída mais refinada
• broot : explorador de arquivos em formato de árvore com navegação aprimorada
• nnn : gerenciador de arquivos de terminal leve e rápido

Análise de uso de espaço em arquivos e diretórios

• ncdu : fornece uma interface intuitiva para du baseada em texto
• dust : substituto mais simples para du, implementado em Rust
• duf : ferramenta de análise de uso de disco com usabilidade melhorada em relação ao df tradicional

Busca de arquivos e código

• fd : substituto rápido e conciso para find, com ótima usabilidade
• ripgrep : substituto ultrarrápido para grep, com suporte a gitignore
• ag : ferramenta de busca em código parecida com ack, mas ainda mais rápida
• fzf : buscador fuzzy de uso geral, útil em pipelines e muitos outros contextos
• bfs : substituto para find baseado em breadth-first

Visualizadores de Git/diff no terminal

• delta : visualiza resultados de git e diff com mais legibilidade

Histórico e processamento de comandos

• mcfly : melhora de forma inovadora a busca e navegação no histórico do shell, com melhor qualidade de busca e UI intuitiva

Processamento de dados

• choose : alternativa mais intuitiva e rápida a cut e a alguns usos de awk
• jq : parser de dados usado como um sed voltado para JSON
• sd : ferramenta de substituição para sed, com find/replace mais amigável

Monitoramento de sistema/processos

• bottom : monitor gráfico de sistema e processos multiplataforma
• glances : versão aprimorada de top/htop
• gtop : monitor de sistema em formato de dashboard no terminal
• procs : comando que substitui ps, escrito em Rust

Benchmarking e rede

• hyperfine : ferramenta de automação de benchmarking de CLI
• gping : ferramenta de ping com saída em gráfico

Clientes HTTP

• httpie : cliente HTTP moderno e amigável para CLI, ideal para testar APIs de desenvolvedor
• curlie : ferramenta que combina o poder do curl com a usabilidade do httpie
• xh : substituto do httpie com foco em desempenho

Navegação entre diretórios e editor

• zoxide : comando cd inteligente inspirado no z
• micro : editor de texto para terminal com recursos modernos

Novos utilitários CLI em destaque

• up : ferramenta de pipeline com pré-visualização em tempo real, permitindo verificar imediatamente a saída dos comandos

Ferramentas de ajuda e documentação

• ManKier : páginas man resumidas, com explicações de comandos mais limpas
• tldr : resumo conciso de páginas man com foco em exemplos
• tealdeer : implementação de tldr em Rust, com execução rápida
• explainshell : analisa automaticamente os argumentos de comandos e explica visualmente seus significados
• cheat.sh : serviço online de ajuda que integra tldr e cheatsheets

Ferramentas GUI

• baobab : analisador de uso de disco com GUI
• stacer : ferramenta GUI de otimização e monitoramento do sistema, incluindo gerenciamento de serviços

[GN⁺]

Comentários do Hacker News

• Essas ferramentas podem até ser objetivamente melhores, mas percebi que configurar esse tipo de coisa toda vez que instalo um SO novo, subo uma VM ou acesso por SSH é um sofrimento sem fim. Ficar configurando em cada ambiente cansa, e eu também não quero misturar ferramentas novas em um lugar e ferramentas tradicionais em outro. Aprender bem as ferramentas clássicas é o jeito mais fácil de tornar a vida mais confortável

  • Algumas pessoas passam a maior parte do tempo no próprio computador, então esse ganho de conveniência tem muito valor. Ainda assim, elas também sabem usar razoavelmente as ferramentas clássicas, então isso basta quando precisam mexer ocasionalmente em outros servidores. Nem todo mundo é administrador de sistemas que precisa ficar entrando em vários servidores diferentes o dia inteiro

  • Algumas ferramentas são tão melhores que valem a pena mesmo com o incômodo extra de instalar. Eu domino bem as ferramentas clássicas, mas fd e ripgrep são sempre melhores

  • Um dos grandes motivos de eu gostar tanto de Nix é poder ter praticamente a mesma configuração em quase qualquer ambiente (desde que eu use Linux ou macOS, só preciso me preocupar com esses dois). Há várias formas de instalar Nix sem precisar de privilégio de root, então consigo recriar meu ambiente em qualquer lugar. Claro, sem Nix as ferramentas clássicas continuam sendo perfeitamente utilizáveis. Não é preciso escolher só um dos lados; dá para ter os dois

  • Quando instalo um SO novo, de qualquer forma preciso instalar os pacotes de que necessito com apt-get, pacman, dnf, brew e afins, além de instalar meu navegador, editor etc. Se entro por SSH, nem GUI eu consigo usar, mas isso não é motivo para evitar ferramentas gráficas. Mesmo que a combinação de ferramentas no ambiente pessoal e no ambiente compartilhado seja diferente, não acho que isso seja um grande problema. Por exemplo, bat não substitui totalmente cat, ele só adiciona syntax highlighting e deixa a vida mais prática. Se não estiver instalado, é só não usar

  • Na minha visão, pela filosofia UNIX de “faça uma coisa e faça bem”, a própria ideia dessas utilidades simples é justamente poder trocá-las facilmente quando surge uma alternativa melhor. Faz sentido aprender primeiro as ferramentas clássicas por questão de carreira, mas acho que também é preciso aprender as alternativas novas. Para mim, mais do que bat ou eza, alternativas que economizam tempo como fd (substituto do find) e sd (substituto do sed) ajudam de verdade

• Para quem acessa centenas de servidores em várias redes e clientes, quase não vale a pena usar ferramentas customizadas. Em 90% dos ambientes elas nem estão instaladas. Eu distribuo algumas poucas via automação, adicionando só o estritamente necessário no ansible-config, mas mantenho a lista bem enxuta. Como 95% dos sistemas que administro são Debian ou Ubuntu, a base é quase sempre a mesma, e eu só acrescento coisas como ack, etckeeper, vim, pv e dstat

  • O ponto-chave aqui é que estamos falando de “servidores”. A maioria desses programas levemente melhores para sysadmin talvez não tenha tanto valor, mas alguns são ferramentas de desenvolvimento de verdade para usar só nas poucas máquinas em que você programa. Exemplos clássicos são ripgrep (um excelente grep recursivo), jq (processador de JSON sem equivalente no kit básico do Unix) e hyperfine (benchmarking)

  • Como trabalho alternando entre Windows e Linux, ferramentas cross-platform excelentes como ripgrep são realmente muito práticas

  • Fico me perguntando se já existe alguma ferramenta ou extensão de SSH que traga automaticamente esses apps para uma sessão SSH remota. Se forem binários pequenos, talvez desse para copiá-los para uma pasta temporária e usar dali, e dá para imaginar a automação desse processo. A questão seria se isso não traz problemas de segurança e se não exigiria permissões extras. No fim, a portabilidade desses apps é a chave. Eu também penso muito nisso

  • O emacs funciona quase como um sistema operacional por si só, então dá para ter um ambiente familiar em qualquer sistema. É daí que vem a frase “GNU is my operating system, linux is just the current kernel”. Como admin veterano, recomendo a quem está começando em Linux que comece pelo comando info e leia todo o manual. Isso já coloca a pessoa muito à frente da maioria dos administradores. Quando você conhece as ferramentas embutidas, a documentação ajuda bastante e fica fácil escrever scripts; esse é justamente o coração da filosofia Linux. Houve uma época em que nem nano existia e só havia vi, mas hoje em dia é simples adicionar editores TUI via automação de CI/CD

  • Não me identifico muito com esses comentários do tipo “eu sou esse tipo de pessoa”. Muita gente simplesmente não liga para o fato de não instalar ferramentas customizadas no remoto. A ideia é aproveitar os benefícios instalando essas ferramentas pelo menos na máquina local

• Acho que essa tabela deveria ter uma coluna extra dizendo “que problema esta ferramenta resolve”. E, para mim, “implementado em Rust” não é um diferencial

  • Já vivi o constrangimento de ouvir numa reunião da empresa alguém dizer que “foi feito em Go” era o diferencial. #facepalm

  • Muitos itens da tabela de fato mencionam problemas reais, como “syntax highlight”, “interface ncurses” e “more intuitive”. O que não ajuda são descrições como “feito em Rust”, “moderno” ou “melhor”

  • O objetivo principal da maioria dessas ferramentas é melhorar a UX

  • Usar uma licença não GPL também não é um diferencial

  • Muitas dessas ferramentas são boas porque também funcionam no Windows

• Essas listas de ferramentas são sempre divertidas. A maioria das pessoas provavelmente conseguiria aproveitar bem uma ou duas ferramentas daqui. Pessoalmente, ripgrep e jq são indispensáveis. ripgrep é o melhor substituto mais próximo de grep, e jq resolve exatamente um problema que eu realmente precisava resolver. Talvez eu experimente lsd e dust. Mesmo quando uma ferramenta nova não me atende diretamente, sou grato por haver gente dedicando tempo a isso. É incrível ver pessoas melhorando aos poucos a caixa de ferramentas da comunidade como um todo

  • Eu escolheria fzf antes de qualquer outro. Gosto muito mais dele do que de rg ou jq

  • ripgrep não é de fato um substituto direto de grep, porque se comporta de maneira diferente. É um programa excelente, mas não é totalmente compatível

  • Admins de Linux como eu costumam ter cada um sua lista bem amarrada dessas ferramentas. Eu montei meu ecossistema principalmente em cima de uma stack GPL, e gosto especialmente deste formato do ikrima.dev

• Eu vivo no terminal, mas essas ferramentas não resolvem problemas que eu precise resolver agora, ou não estão instaladas no meu sistema, e ainda assim por algum motivo têm dezenas de milhares de estrelas no GitHub. Não entendo de onde vem tanta popularidade

  • Alguém que vive mergulhado numa biblioteca musical também pode achar estranho quando um artista fora do seu gosto, ou que nem está na biblioteca, vende milhões de discos. Brincadeiras à parte, eu queria perguntar se você já chegou a testar alguma dessas ferramentas de verdade. Eu também não entendia por que usavam vim, mas depois que usei direito, entendi

  • Você não usa fzf? Sua vida no terminal deve ser bem dura. Além de executá-lo diretamente, os plugins de shell permitem usar Ctrl+R para busca fuzzy no bash_history e Ctrl+T para buscar de forma fuzzy os arquivos do diretório atual, o que é muito útil

  • O conjunto central de ferramentas Unix é tão sólido que dá para trabalhar perfeitamente só com o básico. Muitas dessas alternativas são melhores, mas não são obrigatórias, e além disso a maioria não vem instalada por padrão

  • Perguntando por curiosidade: existe alguma forma elegante, só com as ferramentas Unix embutidas, de fazer um grep recursivo apenas em certas extensões e ignorando arquivos ocultos (.git etc.)? Por exemplo, o padrão rg -g '*.foo' bar é algo que eu uso o tempo todo. O mesmo vale para procurar com fd arquivos que batam com uma regex ou glob. Não encontrei uma forma limpa de fazer isso só com as ferramentas padrão

  • Fico curioso para saber que tipo de trabalho alguém faz o dia todo no terminal sem sentir vontade de melhorar o conjunto de ferramentas. Dá vontade de perguntar se a pessoa escreve todas as próprias ferramentas

• No modo escuro, o texto dos links quase não aparece e fica difícil de ler

• Acho que só jq resolve um problema real que não é atendido pelas ferramentas já existentes. O resto é basicamente diferença de símbolos, desempenho, highlighting ou implementação em Rust

• Eu queria que uma equipe lançasse uma “suite” de ferramentas com design consistente em parâmetros, cores, tabelas etc.

• Durante muito tempo usei htop por considerá-lo mais acessível que top, mas o fato de htop não mostrar threads do kernel por padrão acabou atrapalhando na hora de descobrir a causa de incidentes. Depois disso voltei para top, porque ele mostra todas as informações e me passa mais confiança. Interfaces como htop e btop, para mim, são quase puro exibicionismo

• Este artigo é de 2023. A maior parte das “ferramentas modernas” provavelmente já foi atualizada, e outras novas e da moda podem ter surgido

  • Como há muitas ferramentas, já vale a pena mesmo que só metade sobreviva

  • Minha experiência é justamente o oposto. A maioria dessas ferramentas não passa de uma nova “reinvenção” do conjunto poderoso de ferramentas básicas do GNU, que já são extremamente capazes se você investir tempo para aprendê-las direito