DEV Community: Ewerson Benigno

Pipes e Redirecionamento no Linux: o que eu aprendi estudando o terminal no celular

Ewerson Benigno — Fri, 26 Jun 2026 23:37:57 +0000

Eu estava no Termux, um emulador de terminal para Android, rodando uns comandos básicos de estudo, quando digitei algo simples:

ls > arquivos.txt

Não aconteceu nada. O terminal ficou em silêncio.
Meu primeiro instinto foi achar que o comando tinha falhado. Mas quando rodei cat arquivos.txt, o conteúdo estava lá, o ls tinha funcionado, só que a saída não foi para a tela. Foi para dentro do arquivo.
Esse momento me fez querer entender o que estava acontecendo por baixo. Este artigo é o resultado disso.

Os três canais de todo comando Linux

Antes de falar em pipes e redirecionamento, preciso falar sobre como o Linux enxerga a comunicação de um programa.
Todo processo no Linux tem três canais abertos por padrão:

Canal	Número	O que é
stdin	0	Entrada de dados
stdout	1	Saída normal
stderr	2	Saída de erros

Por padrão, stdout e stderr aparecem na tela, e stdin vem do teclado. Mas você pode mudar isso e é aí que a mágica acontece.

Redirecionamento de saída com >

O operador > redireciona o stdout de um comando para um arquivo.

ls > arquivos.txt

O que acontece aqui:
• ls gera a listagem de arquivos (stdout)
• > intercepta essa saída antes de chegar na tela
• O conteúdo vai para dentro de arquivos.txt
• Se o arquivo não existir, ele é criado
• Se já existir, o conteúdo anterior é sobrescrito
Para adicionar ao invés de sobrescrever, use >>:

ls >> arquivos.txt

Redirecionando erros com 2>

O canal de erros é separado do canal de saída. Para capturá-lo, você usa 2>.

cat arquivo_que_nao_existe.txt 2> erro.txt

Tente rodar os dois e compare:

# Isso imprime o erro na tela
cat arquivo_que_nao_existe.txt

# Isso salva o erro em um arquivo (nada aparece na tela)
cat arquivo_que_nao_existe.txt 2> erro.txt

# Confirme que o erro foi salvo
cat erro.txt

Isso é útil quando você roda um script longo e quer guardar os erros para analisar depois, sem poluir a saída normal.

Juntando stdout e stderr no mesmo arquivo

Às vezes você quer capturar tudo, saída e erro, no mesmo lugar:

comando > tudo.txt 2>&1

O 2>&1 significa: "redirecione o canal 2 (stderr) para onde o canal 1 (stdout) estiver indo."
A ordem importa. Isso aqui não funciona como esperado:

# Ordem errada — resultado não é o que você espera
comando 2>&1 > tudo.txt

Nessa ordem, o 2>&1 é avaliado primeiro — quando ainda não há redirecionamento de stdout, então o stderr é vinculado à tela. Depois o > tudo.txt redireciona só o stdout para o arquivo. Resultado: o arquivo recebe apenas o stdout, e o stderr continua aparecendo na tela. O inverso do que você queria.

Pipes com |: compondo

O pipe | conecta a saída de um comando à entrada do próximo. É como criar uma linha de montagem.

ls -l | grep ".txt"

O que acontece:

ls -l lista todos os arquivos com detalhes
| passa essa saída como entrada para o grep
grep ".txt" filtra e mostra só as linhas que contêm .txt Outro exemplo prático, procurar um processo em execução:

ps aux | grep java

Você pode encadear quantos pipes quiser:

cat arquivo.txt | sort | uniq | wc -l

Isso lê um arquivo, ordena as linhas, remove duplicatas e conta quantas restaram, tudo em um único comando.

tee: saída na tela e no arquivo ao mesmo tempo

O > escolhe entre tela ou arquivo. O tee faz os dois:

ls | tee listagem.txt

A saída aparece na tela e é salva no arquivo simultaneamente. Útil quando você quer acompanhar o que está acontecendo em tempo real e ainda guardar o resultado.

Resumo visual

comando             → stdout → tela (padrão)
comando > arquivo   → stdout → arquivo
comando >> arquivo  → stdout → arquivo (acumula)
comando 2> erros    → stderr → arquivo
comando 2>&1        → stderr → mesmo lugar que stdout
cmd1 | cmd2         → stdout do cmd1 → stdin do cmd2
cmd | tee arquivo   → stdout → tela e arquivo

Por que isso importa

Esses conceitos parecem simples, mas são a base de como scripts shell funcionam, como logs são gerados, como pipelines de dados são construídos, e como você compõe ferramentas pequenas para resolver problemas grandes.
No Linux, cada ferramenta faz uma coisa bem feita. Pipes e redirecionamento são o que permite combiná-las.
Comecei a entender isso rodando um ls no Termux às 19h num sábado. Às vezes o aprendizado começa em lugares assim.

Como pensar em UX mesmo sendo desenvolvedor front-end iniciante

Ewerson Benigno — Sat, 30 May 2026 23:58:17 +0000

Quando iniciei minha primeira Landing page não sabia nada sobre UX.
Sabia estruturar um HTML, sabia usar o CSS e eu tinha um objetivo claro: desenvolver uma Landing page para uma amiga maquiadora. Era meu primeiro projeto, tentei "caprichar" ao máximo, foco nos detalhes. Então percebi que estava fazendo mais do que apenas criar um código, analisava o tempo todo sobre como seria a interação dos clientes dela com a página e como isso se converteria em lucro para o seu negócio.
Somente depois de estudar mais a fundo sobre front-end que entendi como esse "olhar aos detalhes" se chamava: UX - User Experience, a Experiência do Usuário.

O que é UX

Na prática, UX é uma pergunta que você faz antes de escrever qualquer linha de código: “Quem vai usar isso e o que essa pessoa precisa encontrar?”
É isso, parece algo básico, mas muda completamente a forma como você constrói o seu projeto. Um desenvolvedor que não pensa em UX olha apenas a estética, ele fica naquilo que é atrativo aos olhos do usuário. Um desenvolvedor que pensa em UX desenvolve pensando na necessidade do cliente.

Decisões de UX que você toma sem perceber
Muitas pessoas não percebem mas já praticam UX sem nem perceber.
Toda vez que você decide onde colocar um botão, um texto, um link ou como quer organizar as seções da sua página, você está tomando uma decisão de UX.
No meu projeto da landing page, tomei várias dessas decisões intuitivamente:
Coloquei o WhatsApp no footer com link direto. O visitante que chega até o final da página já leu tudo e quer entrar em contato, facilitar esse clique é UX.
Posicionei os depoimentos antes do footer. Não foi por acaso, depoimentos constroem confiança. Faz sentido mostrá-los antes de pedir que o visitante entre em contato.
Adicionei um botão de call-to-action no Hero. A primeira seção da página precisa deixar claro o que o visitante deve fazer. Um botão “Saiba mais” ou “Entre em contato” elimina a dúvida.
Todas essas ações têm um princípio em comum, elas pensam no usuário antes de pensar no código.

A diferença entre UI e UX
Antes eu confundia bastante os termos, agora entendo claramente.
UI é o que o usuário vê. É o botão rosa com bordas arredondadas, é a fonte elegante, é a paleta de cores coerente. UI é sobre estética.
UX é o que o usuário sente e faz. É o botão estar no lugar certo, é o texto do botão ser claro o suficiente para o usuário saber o que vai ler ao clicar, é a página carregar rápido o suficiente para ele não desistir. UX é sobre comportamento.
Você pode ter um site com UI perfeita e UX terrível. Um site lindo onde ninguém encontra o que precisa é um site com problema de UX.
O contrário também existe: sites simples visualmente, mas com navegação tão intuitiva que o usuário encontra tudo em segundos. Boa UX, UI modesta.
O ideal, claro, é ter os dois.

Como aplicar UX sem ser especialista
Você não precisa de certificação para começar a pensar em UX. Você pode se fazer algumas perguntas simples na hora de desenvolver:

“Em 3 segundos, o usuário entende o que esse site oferece?”
Se a resposta for não, o Hero da sua página precisa ser refeito. O visitante decide em poucos segundos se vai ficar ou sair.
“Qual é a ação que quero que o usuário tome?”
Entrar em contato, comprar, ou se inscrever, essa ação precisa estar visível, clara e fácil de executar.
“Como isso fica no celular?”
A maioria dos acessos hoje são feitos no mobile. Se você só testa no computador, está ignorando boa parte dos seus usuários.
“Estou facilitando ou complicando?”
Cada clique a mais, cada informação desnecessária, cada campo de formulário que não precisa estar lá, tudo isso é fricção. UX é sobre remover fricção.

Conclusão
Se você está começando no front-end e acha que UX é assunto para depois, é melhor repensar isso.
Você não precisa dominar ferramentas complexas ou ter anos de experiência. Precisa desenvolver o hábito de perguntar: “quem vai usar isso, e o que essa pessoa precisa?”
Essa pergunta, feita com consistência, vai separar o código que você escreve do código que outros escrevem.
E o melhor: você provavelmente já está praticando UX sem perceber. Agora é só dar nome ao que você faz.