Guia prático para transformar Markdown, documentos técnicos, histórias, manuais, anotações e textos longos em arquivos
.txtbonitos, legíveis, com largura controlada e estética clássica de terminal.
Sumário
- O que é esse estilo?
- Por que 72, 76 ou 80 colunas?
- O caminho recomendado
- Ferramentas principais
- Instalação no Linux
- Instalação no macOS
- Instalação no Windows
- Criando o Markdown de origem
- Convertendo Markdown para
.txt - Reformatando
.txtexistente - Como fazer isso no Windows sem WSL
- Scripts prontos
- Fluxo com VS Code
- Documentação técnica
- Histórias, ensaios e textos literários
- Publicando na web
- Erros comuns
- Receita curta
- 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:
| Largura | Uso recomendado |
|---|---|
| 72 | e-mails, citações, textos que podem receber indentação |
| 76 | melhor equilíbrio para documentação e leitura confortável |
| 78 | próximo do terminal clássico, ainda com pequena margem |
| 80 | esté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
| Ferramenta | Serve para | Melhor uso |
|---|---|---|
pandoc | converter Markdown, HTML, DOCX e outros formatos para .txt | documentos estruturados |
fmt | reformatar parágrafos simples em largura fixa | textos corridos |
fold | quebrar linhas mecanicamente | uso bruto e rápido |
par | formatar parágrafos com mais controle | e-mails, citações, terminal |
awk | verificar linhas acima do limite | auditoria |
less | ler resultado no terminal | revisão |
| PowerShell | quebrar texto no Windows sem Unix tools | fluxo nativo Windows |
| VS Code | escrever e revisar com régua de coluna | autoria 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
- Pandoc User's Guide: https://pandoc.org/MANUAL.html
- Pandoc releases: https://github.com/jgm/pandoc/releases
- GNU Coreutils:
fmt: https://www.gnu.org/software/coreutils/manual/html_node/fmt-invocation.html - GNU Coreutils:
fold: https://www.gnu.org/software/coreutils/manual/html_node/fold-invocation.html - Microsoft WinGet: https://learn.microsoft.com/en-us/windows/package-manager/winget/
- MSYS2: https://www.msys2.org/
- Git for Windows: https://gitforwindows.org/
- Visual Studio Code: https://code.visualstudio.com/
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
- 001
- 002
- 003
- 004
- 005