rtk ls returns "(empty)" for non-empty directories on non-English locales

[ALArvi019]

Summary

When the system locale is not English (e.g. LANG=es_ES.UTF-8), rtk ls <dir> reports a directory as empty even when it contains many files. Likely affects other filters too.

Reproduce

$ LANG=es_ES.UTF-8 rtk ls /tmp
(empty)

$ LANG=es_ES.UTF-8 rtk ls -v /tmp
Chars: 8635 → 8 (100% reduction)
(empty)

$ LC_ALL=C rtk ls /tmp
.ICE-unix/
.X11-unix/
...

Tested on rtk 0.35.0 (master, commit 314978cd), Linux, LANG=es_ES.UTF-8.

Root cause

src/cmds/system/ls.rs uses a hardcoded English-month regex as the anchor for parsing ls -la rows:

static ref LS_DATE_RE: Regex = Regex::new(
    r"\s+(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\s+\d{1,2}\s+(?:\d{4}|\d{2}:\d{2})\s+"
).unwrap();

src/core/runner.rs::run_filtered spawns the native subprocess without overriding locale, so on non-English systems ls -la emits month names in the user's language (ene feb mar abr… in Spanish). The regex never matches, compact_ls returns no entries, and the filter prints (empty).

Impact

Not just cosmetic — the LLM agent receives (empty) and may reasonably conclude the directory has no files. In my setup Claude Code was being told that directories with 40+ real files were empty. Silent data corruption for the agent's worldview is arguably worse than a visible error, because the agent will act on the wrong information.

Likely affects any other filter whose regexes assume English output from subcommands (git with LC_MESSAGES, find, stat, etc.).

Suggested fix

One-line patch in src/core/runner.rs::run_filtered, right before cmd.output():

cmd.env(\"LC_ALL\", \"C\");

Forces all filtered subcommands to emit C-locale output, which matches the existing English regexes. A single fix covers every filter that goes through run_filtered, so it prevents the same bug from appearing in other commands later.

I verified locally against rtk ls, rtk find, rtk grep, rtk git status — all keep working and the (empty) issue goes away.

Deliberately not applying the same env override to run_passthrough, since there the output is shown verbatim to the user and should respect their real locale.

Environment

• rtk 0.35.0 (master, commit 314978cd)
• OS: Linux (Ubuntu-family)
• Locale: LANG=es_ES.UTF-8, all LC_* in Spanish

Happy to open a PR if helpful.

[pszymkowiak]

[w] wshm · Automated triage by AI

🔍 Automated Triage

🐛 Category	bug
🟠 Priority	high
🎯 Confidence	96%

Summary

Locale-dependent regex in run_filtered causes rtk ls (and other filters) to silently return empty output on non-English systems; fix LC_ALL=C in runner.rs, PR #1338 already in progress.

This looks like a simple fix. Only repo maintainers can trigger auto-fix.

📁 Relevant files

• src/core/runner.rs
• src/cmds/system/ls.rs

---

Triaged automatically by wshm · This is an automated analysis, not a human review.

[aestilog]

Shell wrapper workaround. Tested on macOS 26.3.

mv ~/.local/bin/rtk ~/.local/bin/rtk-bin && \
cat > ~/.local/bin/rtk << 'WRAPPER'
#!/bin/sh
export LC_ALL=C
exec "$HOME/.local/bin/rtk-bin" "$@"
WRAPPER
chmod +x ~/.local/bin/rtk

[NycolasAbreu]

Temporary fix for me:

Added to ~/.bashrc:

alias rtk='LC_ALL=C.UTF-8 rtk'

[Petrusreno]

Confirming this bug on macOS 15 (Darwin 25.4.0) with rtk 0.36.0, LANG=pt_BR.UTF-8. Every rtk ls returns (empty) regardless of directory contents.

With LC_ALL=C rtk ls the output is correct. The proposed one-line patch in run_filtered would resolve it.

Impact here is exactly as described: the Claude Code hook rewrites ls → rtk ls transparently, so the agent was being told every directory is empty. For anyone hitting this before the upstream fix ships, a drop-in wrapper works:

# ~/.local/bin/rtk (must come before /opt/homebrew/bin in PATH)
#!/usr/bin/env bash
exec env LC_ALL=C /opt/homebrew/bin/rtk "$@"

The wrapper preserves rtk's hook integrity check (only PATH resolution changes, binary and hook untouched).

[xihale]

I modified ls.rs

let mut cmd = resolved_command("ls");
+ cmd.env("LC_ALL", "C");
cmd.arg("-la");

I think that that rtk relay shows for agents, english results maybe better understanding for agents, so I did so.

[techouse]

For me it produces (empty) even with en_GB.UTF-8