rtk-ai/rtk

feat(rewrite): strip trailing stderr redirects before pattern matching

Open

#530 aberto em 12 de mar. de 2026

Ver no GitHub
 (5 comments) (0 reactions) (0 assignees)Rust (2.914 forks)batch import
area:clieffort-smallenhancementgood first issuepriority:highresolved-pending-close

Métricas do repositório

Stars
 (48.085 stars)
Métricas de merge de PR
 (Mesclagem média 11d 1h) (45 fundiu PRs em 30d)

Description

Description

rtk rewrite doesn't match commands that have trailing 2>&1 or 2>/dev/null, because the redirect suffix is part of the string passed to pattern matching.

Reproduction

# These match:
rtk rewrite "git status"        # -> rtk git status ✓
rtk rewrite "find . -name '*.ts'"  # -> rtk find . -name '*.ts' ✓

# These don't match (exit 1):
rtk rewrite "git status 2>&1"              # -> no match ✗
rtk rewrite "find . -name '*.ts' 2>&1"     # -> no match ✗
rtk rewrite "ls -la 2>/dev/null"           # -> no match ✗

Impact

Claude Code appends 2>&1 to the vast majority of Bash commands. This means the hook-based rewrite misses most commands that would otherwise match.

From rtk discover on my project: ~975K tokens missed, many from commands that would match if not for the 2>&1 suffix.

Suggested fix

In rtk rewrite, strip trailing 2>&1 / 2>/dev/null before pattern matching, then re-append to the rewritten output.

Workaround: I've added pre-processing to my hook script to strip these before calling rtk rewrite.

Environment

  • rtk 0.28.2
  • macOS Darwin 25.3.0

Guia do colaborador

Direção de pesquisa
Examine o código de correspondência de padrões do comando rewrite para identificar onde os redirecionamentos de stderr finais (2>&1, 2>/dev/null) devem ser removidos antes da correspondência e, em seguida, modifique a lógica para removê los e reanexá los.
Pilha de tecnologia
rust
Domain
clibackend
Tipo Issue
Funcionalidade
DifficultyDificuldade de implementação estimada para um novo contribuidor, de 1 para alterações muito pequenas a 5 para trabalho de nível especializado.
2
Tempo estimadoUm intervalo de tempo aproximado para um colaborador experiente investigar, implementar, testar e preparar um pull request.
1-3 horas
Status da atividadeQuão disponível o issue aparece agora: novo, ativo, obsoleto, bloqueado ou aguardando entrada do mantenedor.
Recente
ClarityCom que clareza o issue explica a mudança esperada, os critérios de aceitação e a próxima etapa.
Claro
Prerequisites
RustCLI
Simpatia para novatosUma pontuação de 1 a 100 que estima o quão acessível este issue é para colaboradores iniciantes.
75