Murad Library
Murad LibraryREF-0384MD

Como criar textos `.txt` no estilo clássico de documentação Unix

Catalogued
Reading
18 min read

Guia prático para transformar Markdown, documentos técnicos, histórias, manuais, anotações e textos longos em arquivos .txt bonitos, legíveis, com largura controlada e estética clássica de terminal.


Sumário

  1. O que é esse estilo?
  2. Por que 72, 76 ou 80 colunas?
  3. O caminho recomendado
  4. Ferramentas principais
  5. Instalação no Linux
  6. Instalação no macOS
  7. Instalação no Windows
  8. Criando o Markdown de origem
  9. Convertendo Markdown para .txt
  10. Reformatando .txt existente
  11. Como fazer isso no Windows sem WSL
  12. Scripts prontos
  13. Fluxo com VS Code
  14. Documentação técnica
  15. Histórias, ensaios e textos literários
  16. Publicando na web
  17. Erros comuns
  18. Receita curta
  19. Fontes e referências

1. O que é esse estilo?

Você provavelmente já viu arquivos .txt assim pela internet:

INTRODUCTION
============

This is a long technical document formatted as plain text. The lines are
manually wrapped so they fit nicely inside an old terminal window, usually
around 72 to 80 columns wide.

1.1 Basic idea

  - plain text
  - fixed-width font
  - manual line wrapping
  - simple headings
  - readable in terminals, browsers and old editors

Esse tipo de documento parece simples, mas não é bagunçado. Ele segue uma tradição forte de documentação Unix, RFCs, manuais de software, HOWTOs, README antigos, zines digitais, BBS, Gopher, Gemini e textos distribuídos em .txt.

A lógica é:

  • usar texto puro;
  • limitar as linhas a 72, 76, 78 ou 80 colunas;
  • escrever pensando em fonte monoespaçada;
  • usar títulos simples;
  • preservar compatibilidade máxima;
  • evitar dependência de HTML, CSS, PDF, Word ou editor específico.

É visualmente simples, mas estruturalmente elegante.

O segredo é este: texto puro bom não é texto sem forma. Pelo contrário. Como você não tem CSS, a estrutura precisa ser mais cuidadosa.


2. Por que 72, 76 ou 80 colunas?

A largura de 80 colunas vem da tradição dos terminais antigos. Muitos terminais exibiam 80 caracteres por linha, então documentação técnica era escrita para caber nesse espaço.

Mas usar exatamente 80 nem sempre é a melhor escolha. Na prática:

LarguraUso recomendado
72e-mails, citações, textos que podem receber indentação
76melhor equilíbrio para documentação e leitura confortável
78próximo do terminal clássico, ainda com pequena margem
80estética terminal pura, mas menos flexível

Minha recomendação prática:

Use 76 colunas.

76 é largo o bastante para não quebrar demais e estreito o bastante para ficar bonito em terminal, navegador e editor de texto.


3. O caminho recomendado

Há dois problemas diferentes:

Problema 1: escrever documentação estruturada e gerar .txt bonito.
Problema 2: pegar um .txt bagunçado e reformatar as linhas.

Para o primeiro caso, use:

Markdown -> Pandoc -> TXT formatado

Para o segundo caso, use:

TXT existente -> fmt/par/fold/PowerShell -> TXT reformatado

O melhor fluxo moderno é:

1. Escreva em Markdown.
2. Converta com Pandoc usando --columns=76.
3. Revise em fonte monoespaçada.
4. Verifique linhas longas.
5. Publique o .txt.

4. Ferramentas principais

FerramentaServe paraMelhor uso
pandocconverter Markdown, HTML, DOCX e outros formatos para .txtdocumentos estruturados
fmtreformatar parágrafos simples em largura fixatextos corridos
foldquebrar linhas mecanicamenteuso bruto e rápido
parformatar parágrafos com mais controlee-mails, citações, terminal
awkverificar linhas acima do limiteauditoria
lessler resultado no terminalrevisão
PowerShellquebrar texto no Windows sem Unix toolsfluxo nativo Windows
VS Codeescrever e revisar com régua de colunaautoria confortável

A diferença brutal

Pandoc  = entende estrutura.
fmt     = entende parágrafos simples.
par     = é fmt vitaminado para terminal/e-mail.
fold    = quebra linha na marretada.
PowerShell = resolve no Windows quando você não quer instalar ambiente Unix.

Se o texto tem títulos, listas, blocos de código e seções, use Pandoc.

Se o texto é só um bloco enorme de parágrafos, fmt ou PowerShell resolvem.


5. Instalação no Linux

Debian, Ubuntu e derivados

sudo apt update
sudo apt install pandoc coreutils par

fmt e fold normalmente já vêm no pacote coreutils.

Fedora

sudo dnf install pandoc coreutils par

Arch Linux

sudo pacman -S pandoc coreutils par

Teste

pandoc --version
fmt --version
fold --version

6. Instalação no macOS

Com Homebrew:

brew install pandoc par

O macOS já traz várias ferramentas Unix, mas algumas opções podem variar em relação ao GNU/Linux. Para um ambiente mais previsível, você pode usar também os GNU coreutils:

brew install coreutils

Teste:

pandoc --version
fmt --version

7. Instalação no Windows

No Windows existem vários caminhos. Não trate todos como equivalentes; eles servem para perfis diferentes.

Opção A — Pandoc nativo no Windows

Esta é a opção mais limpa para converter Markdown para .txt.

Com Winget

No PowerShell:

winget install --id JohnMacFarlane.Pandoc -e

Depois teste:

pandoc --version

Com Chocolatey

choco install pandoc

Com Scoop

scoop install pandoc

Com instalador manual

Baixe o instalador .msi ou .zip na página oficial de releases do Pandoc e instale normalmente.

Depois feche e abra o terminal novamente.

Opção B — WSL

Se você já usa Linux dentro do Windows, esta é a opção mais parecida com um servidor Debian/Ubuntu.

No PowerShell como administrador:

wsl --install

Dentro do Ubuntu/WSL:

sudo apt update
sudo apt install pandoc coreutils par

Aí você usa os mesmos comandos do Linux:

pandoc manual.md -t plain --columns=76 -o manual.txt
fmt -w 76 entrada.txt > saida.txt

Opção C — Git Bash

O Git for Windows traz um ambiente tipo Unix com Bash e várias ferramentas. É útil se você já usa Git.

Instale Git for Windows, abra Git Bash e teste:

pandoc --version
fmt --version
fold --version

Atenção: o Git Bash pode não trazer tudo. Se fmt não existir, use MSYS2, WSL ou PowerShell.

Opção D — MSYS2

MSYS2 é uma forma mais séria de ter ferramentas Unix no Windows.

Depois de instalar MSYS2, abra o terminal MSYS2 e rode:

pacman -Syu
pacman -S mingw-w64-ucrt-x86_64-pandoc coreutils

Teste:

pandoc --version
fmt --version

Opção E — Só PowerShell

Se você não quer instalar Git Bash, WSL ou MSYS2, ainda dá para fazer o básico com PowerShell.

Você perde um pouco da estética Unix, mas ganha simplicidade no Windows puro.

Veja a seção 11.


8. Criando o Markdown de origem

Crie um arquivo chamado manual.md:

# Runv.Club Manual

Runv.Club is a small pubnix for shell accounts, static pages, weird
experiments, personal tools and quiet internet infrastructure.

## Services

The instance provides a few basic services for members:

- shell account
- static web hosting
- email
- IRC community
- small terminal toys
- personal garden

## Philosophy

The goal is not to become a giant platform. The goal is to preserve a small,
readable and human-scale corner of the internet.

Esse Markdown é normal. A mágica vem na conversão.


9. Convertendo Markdown para .txt

Linux, macOS, Windows, WSL, Git Bash ou MSYS2

Para gerar texto com 76 colunas:

pandoc manual.md -t plain --columns=76 -o manual.txt

Para 80 colunas:

pandoc manual.md -t plain --columns=80 -o manual.txt

Para 72 colunas:

pandoc manual.md -t plain --columns=72 -o manual.txt

A opção importante é:

--columns=76

Ela define a largura da saída em texto puro.

No PowerShell

Se o Pandoc estiver instalado nativamente no Windows:

pandoc manual.md -t plain --columns=76 -o manual.txt

Sim, é o mesmo comando.

Convertendo DOCX para TXT clássico

Você também pode transformar um .docx em .txt:

pandoc documento.docx -t plain --columns=76 -o documento.txt

No PowerShell:

pandoc .\documento.docx -t plain --columns=76 -o .\documento.txt

Convertendo HTML para TXT

pandoc pagina.html -t plain --columns=76 -o pagina.txt

Ou direto de uma URL:

pandoc -f html -t plain --columns=76 https://example.com/artigo.html -o artigo.txt

Nem sempre a conversão de HTML fica perfeita. Sites cheios de menu, script, propaganda e layout moderno podem gerar lixo. Para resultado limpo, Markdown como origem ainda é melhor.


10. Reformatando .txt existente

Com fmt

Se você já tem um .txt com linhas gigantes:

fmt -w 76 entrada.txt > saida.txt

Ou:

fmt -w 80 entrada.txt > saida.txt

Exemplo de entrada:

Este é um parágrafo muito longo que foi escrito em uma única linha e precisa ser quebrado de forma decente para caber em uma largura fixa de terminal.

Depois de:

fmt -w 76 entrada.txt > saida.txt

Saída aproximada:

Este é um parágrafo muito longo que foi escrito em uma única linha e precisa
ser quebrado de forma decente para caber em uma largura fixa de terminal.

Com fold

fold -s -w 76 entrada.txt > saida.txt

A opção -s tenta quebrar em espaços.

Mas seja honesto: fold é burro. Ele não entende estrutura. Use só quando você quer forçar quebra rapidamente.

Com par

par 76 < entrada.txt > saida.txt

par é muito bom para:

  • e-mails;
  • citações com >;
  • blocos indentados;
  • texto de terminal;
  • notas antigas.

Mas para o uso comum, Pandoc e fmt resolvem.


11. Como fazer isso no Windows sem WSL

Esta seção é importante. Muita gente fala “usa fmt” como se todo mundo vivesse no Debian. No Windows puro, você pode fazer bastante coisa só com Pandoc e PowerShell.

11.1 Converter Markdown para TXT com Pandoc nativo

No PowerShell:

pandoc .\manual.md -t plain --columns=76 -o .\manual.txt

Ver o resultado:

Get-Content .\manual.txt

Abrir no Bloco de Notas:

notepad .\manual.txt

Abrir no VS Code:

code .\manual.txt

11.2 Verificar linhas maiores que 76 caracteres no PowerShell

Get-Content .\manual.txt | ForEach-Object -Begin { $n = 0 } -Process {
    $n++
    if ($_.Length -gt 76) {
        "$n: $($_.Length) chars: $_"
    }
}

Versão em uma linha:

$n=0; Get-Content .\manual.txt | % { $n++; if ($_.Length -gt 76) { "$n: $($_.Length) chars: $_" } }

11.3 Quebrar parágrafos no PowerShell

Crie um arquivo chamado Wrap-Text.ps1:

param(
    [Parameter(Mandatory=$true)]
    [string]$InputFile,

    [string]$OutputFile = "saida.txt",

    [int]$Width = 76
)

$text = Get-Content -Raw -Encoding UTF8 $InputFile

$paragraphs = $text -split "(\r?\n\s*\r?\n)"

$result = foreach ($part in $paragraphs) {
    if ($part -match "^\r?\n\s*\r?\n$") {
        ""
        continue
    }

    $trimmed = $part.Trim()

    if ($trimmed -eq "") {
        ""
        continue
    }

    # Preserva blocos que parecem código, listas já indentadas ou linhas especiais.
    if ($trimmed -match "^(    |\t|```|>|[-*+] |\d+\. )") {
        $part.TrimEnd()
        continue
    }

    $words = $trimmed -split "\s+"
    $line = ""

    foreach ($word in $words) {
        if ($line.Length -eq 0) {
            $line = $word
        }
        elseif (($line.Length + 1 + $word.Length) -le $Width) {
            $line += " " + $word
        }
        else {
            $line
            $line = $word
        }
    }

    if ($line.Length -gt 0) {
        $line
    }

    ""
}

$result | Set-Content -Encoding UTF8 $OutputFile

Uso:

.\Wrap-Text.ps1 -InputFile .\entrada.txt -OutputFile .\saida.txt -Width 76

Se o Windows bloquear execução de script:

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

Depois rode novamente.

11.4 Script PowerShell para Markdown -> TXT clássico

Crie md2txt-classic.ps1:

param(
    [Parameter(Mandatory=$true)]
    [string]$InputFile,

    [int]$Width = 76
)

if (-not (Test-Path $InputFile)) {
    Write-Error "Arquivo não encontrado: $InputFile"
    exit 1
}

$OutputFile = [System.IO.Path]::ChangeExtension($InputFile, ".txt")

pandoc $InputFile -t plain --columns=$Width -o $OutputFile

Write-Host "Gerado: $OutputFile"
Write-Host "Verificando linhas maiores que $Width caracteres..."

$n = 0
Get-Content $OutputFile | ForEach-Object {
    $n++
    if ($_.Length -gt $Width) {
        Write-Host "$n: $($_.Length) chars"
    }
}

Uso:

.\md2txt-classic.ps1 .\manual.md

Com 80 colunas:

.\md2txt-classic.ps1 .\manual.md -Width 80

11.5 Criar comando global no Windows

Crie uma pasta:

mkdir $HOME\bin

Mova o script para lá:

Move-Item .\md2txt-classic.ps1 $HOME\bin\

Adicione $HOME\bin ao PATH do usuário:

[Environment]::SetEnvironmentVariable(
    "Path",
    [Environment]::GetEnvironmentVariable("Path", "User") + ";$HOME\bin",
    "User"
)

Feche e abra o PowerShell.

Agora você pode rodar:

md2txt-classic.ps1 .\manual.md

12. Scripts prontos

12.1 Script Bash: md2txt-classic

Crie:

mkdir -p ~/bin
nano ~/bin/md2txt-classic

Cole:

#!/usr/bin/env bash
set -euo pipefail

if [ "$#" -lt 1 ]; then
  echo "Uso: md2txt-classic arquivo.md [largura]"
  echo "Exemplo: md2txt-classic manual.md 76"
  exit 1
fi

INPUT="$1"
WIDTH="${2:-76}"
OUTPUT="${INPUT%.*}.txt"

pandoc "$INPUT" -t plain --columns="$WIDTH" -o "$OUTPUT"

echo "Gerado: $OUTPUT"
echo "Verificando linhas maiores que $WIDTH caracteres..."
awk -v w="$WIDTH" 'length($0)>w { print NR ": " length($0) " chars: " $0 }' "$OUTPUT" || true

Permissão:

chmod +x ~/bin/md2txt-classic

Adicione ao PATH, se necessário:

echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

Uso:

md2txt-classic manual.md
md2txt-classic manual.md 80

12.2 Makefile para um documento

Crie Makefile:

TXT_WIDTH = 76
SRC = manual.md
OUT = manual.txt

all: txt

txt:
	pandoc $(SRC) -t plain --columns=$(TXT_WIDTH) -o $(OUT)

check:
	awk 'length($$0)>$(TXT_WIDTH) { print NR ": " length($$0) " chars: " $$0 }' $(OUT)

view:
	less $(OUT)

clean:
	rm -f $(OUT)

Uso:

make
make check
make view
make clean

12.3 Makefile para vários textos

Estrutura:

texts/
├── source/
│   ├── manual.md
│   ├── manifesto.md
│   └── story.md
├── dist/
│   ├── manual.txt
│   ├── manifesto.txt
│   └── story.txt
└── Makefile

Makefile:

TXT_WIDTH = 76
SRC_DIR = source
OUT_DIR = dist
SOURCES = $(wildcard $(SRC_DIR)/*.md)
OUTPUTS = $(patsubst $(SRC_DIR)/%.md,$(OUT_DIR)/%.txt,$(SOURCES))

all: $(OUTPUTS)

$(OUT_DIR)/%.txt: $(SRC_DIR)/%.md
	mkdir -p $(OUT_DIR)
	pandoc $< -t plain --columns=$(TXT_WIDTH) -o $@

check:
	@for f in $(OUTPUTS); do \
		echo "Checking $$f"; \
		awk 'length($$0)>$(TXT_WIDTH) { print FILENAME ":" NR ": " length($$0) " chars: " $$0 }' $$f; \
	done

clean:
	rm -f $(OUT_DIR)/*.txt

Gerar tudo:

make

Verificar tudo:

make check

13. Fluxo com VS Code

VS Code é uma boa oficina para esse tipo de texto, desde que você configure direito. Sem isso, você vai escrever Markdown moderno e só perceber a quebra feia depois.

13.1 Ative régua de coluna

Abra as configurações JSON do VS Code e adicione:

{
  "editor.rulers": [76, 80],
  "editor.wordWrap": "off",
  "editor.fontFamily": "Cascadia Mono, Consolas, 'Courier New', monospace"
}

Isso mostra onde ficam as colunas 76 e 80.

13.2 Use preview de Markdown, mas não confie só nele

O preview do Markdown mostra o texto renderizado, não o .txt final. Para esse fluxo, o arquivo final é o .txt, então sempre gere e revise o resultado.

13.3 Tarefa do VS Code para gerar TXT

Crie .vscode/tasks.json:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Gerar TXT clássico",
      "type": "shell",
      "command": "pandoc manual.md -t plain --columns=76 -o manual.txt",
      "problemMatcher": []
    }
  ]
}

No VS Code:

Terminal -> Run Task -> Gerar TXT clássico

13.4 No Windows com PowerShell

Se o terminal padrão do VS Code for PowerShell:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Gerar TXT clássico",
      "type": "shell",
      "command": "pandoc .\\manual.md -t plain --columns=76 -o .\\manual.txt",
      "problemMatcher": []
    }
  ]
}

14. Documentação técnica

Um documento técnico em .txt clássico pode seguir esta estrutura:

TITLE
=====

1. Introduction

2. Requirements

3. Installation

4. Configuration

5. Usage

6. Troubleshooting

7. References

Em Markdown:

# Title

## 1. Introduction

## 2. Requirements

## 3. Installation

## 4. Configuration

## 5. Usage

## 6. Troubleshooting

## 7. References

Converta:

pandoc document.md -t plain --columns=76 -o document.txt

Dica importante para documentação técnica

Não tente fazer tabela complexa demais em .txt.

Bom:

Name        Role
----        ----
runv        pubnix
nyx         server
skull       vps

Ruim:

| serviço | host | porta | reverse proxy | backup | owner | SLA | status |

Tabela gigante em texto puro vira uma porcaria. Use listas.


15. Histórias, ensaios e textos literários

Para textos literários, histórias ou ensaios, não exagere na estrutura técnica. O charme está no texto respirando.

Exemplo:

# The Last Terminal

There was still one machine running in the basement.

Nobody remembered who installed it. Nobody remembered why it mattered. But
once a week, someone would log in, read the system mail, clean the old logs and
leave a short note in `/var/local/diary`.

## I. The Login

The prompt appeared after three seconds.

That was the first strange thing. Old machines were supposed to be slow. This
one felt patient instead.

Converter:

pandoc historia.md -t plain --columns=76 -o historia.txt

Resultado: texto com cara de arquivo encontrado em algum canto empoeirado da internet. Exatamente o charme.


16. Publicando na web

Um .txt pode ser publicado diretamente em um servidor web.

Exemplo:

/var/www/html/manual.txt

Acesso:

https://example.com/manual.txt

Nginx

Na maioria dos casos, o Nginx já serve .txt como text/plain.

Se quiser garantir:

location ~ \.txt$ {
    default_type text/plain;
    charset utf-8;
}

Apache

Normalmente também já funciona. Se precisar forçar:

AddType text/plain .txt
AddDefaultCharset UTF-8

GitHub Pages

Você pode publicar o .txt em um repositório e acessar diretamente:

https://usuario.github.io/projeto/manual.txt

Dica estética

Se você quer manter a estética de terminal no navegador, o .txt puro já faz isso parcialmente. Mas cada navegador usa sua própria fonte padrão. Para controle visual total, aí você precisaria criar uma página HTML com <pre>. Só que isso deixa de ser .txt puro.


17. Erros comuns

1. Quebrar tudo com fold sem revisar

fold pode destruir blocos de código, URLs e tabelas.

2. Usar fonte proporcional para revisar

Revise em fonte monoespaçada. Caso contrário, você não percebe alinhamento errado.

3. Fazer tabelas grandes demais

Tabela em .txt é possível, mas tabela complexa vira sofrimento.

4. Quebrar URLs manualmente

URLs quebradas são irritantes. Melhor deixar uma URL passar de 76 colunas do que torná-la inútil.

5. Achar que .txt bonito é falta de estrutura

É o contrário. Sem CSS, a estrutura precisa ser melhor.

6. Converter DOCX sujo e esperar milagre

Pandoc é ótimo, mas DOCX cheio de caixa de texto, imagem, cabeçalho maluco e formatação visual pode sair esquisito. Quanto mais limpo o documento de origem, melhor a saída.

7. Esquecer de UTF-8

Use UTF-8. Especialmente em português. Acentos quebrados são o tipo de coisa que destrói o prazer de ler texto puro.

No PowerShell moderno, prefira:

Set-Content -Encoding UTF8
Get-Content -Encoding UTF8

18. Receita curta

Markdown para TXT clássico

pandoc entrada.md -t plain --columns=76 -o saida.txt

Verificar linhas longas no Linux/macOS/WSL/Git Bash

awk 'length($0)>76 { print NR ": " length($0) " chars: " $0 }' saida.txt

Verificar linhas longas no PowerShell

$n=0; Get-Content .\saida.txt | % { $n++; if ($_.Length -gt 76) { "$n: $($_.Length) chars: $_" } }

Reformatar .txt simples com fmt

fmt -w 76 entrada.txt > saida.txt

Reformatar .txt simples com PowerShell

.\Wrap-Text.ps1 -InputFile .\entrada.txt -OutputFile .\saida.txt -Width 76

Minha recomendação final

Linux/macOS/WSL:  Markdown + Pandoc + awk + less
Windows simples:  Pandoc nativo + PowerShell + VS Code
Windows nerd:     WSL ou MSYS2 + Pandoc + coreutils

19. Fontes e referências


Conclusão

O jeito mais inteligente de criar textos .txt clássicos hoje é não escrever tudo manualmente em .txt desde o começo.

Escreva em Markdown, que é confortável e estruturado. Depois gere a versão final em texto puro com Pandoc.

A combinação ideal é:

Markdown para autoria
Pandoc para conversão
76 colunas para estética clássica
awk ou PowerShell para auditoria
less, VS Code ou Notepad++ para leitura final

Esse formato é simples, portátil e resistente. Não depende de plataforma, editor, navegador moderno ou layout quebradiço. Um bom .txt é quase infraestrutura cultural: pequeno, legível e difícil de matar.


Compilado e revisado por Pablo Murad, 2026.

Did this resonate?

Related documents