rtk ls returns "(empty)" with non-English locales (LANG=de_DE.UTF-8, fr_FR.UTF-8)

Summary

rtk ls silently returns "(empty)" on any directory when LANG is set to a non-English UTF-8 locale. Exit code is 0, no error message. The parser appears to be hardcoded to English/C locale output formats.

Environment

rtk 0.37.2 (installed via Homebrew)
macOS (Apple Silicon)
iTerm2 with "Set locale environment variables automatically" enabled (iTerm's default behavior on systems with non-English system language)

Minimal Reproduction

mkdir /tmp/rtk-bugtest
cd /tmp/rtk-bugtest
touch a.txt b.txt c.txt
mkdir src

# Works correctly:
env -i HOME=$HOME PATH=/opt/homebrew/bin:/usr/bin:/bin \
    LANG=en_US.UTF-8 rtk ls /tmp/rtk-bugtest
# Output:
#   src/
#   a.txt  0B
#   b.txt  0B
#   c.txt  0B
#   Summary: 3 files, 1 dirs (3 .txt)

env -i HOME=$HOME PATH=/opt/homebrew/bin:/usr/bin:/bin \
    LANG=C.UTF-8 rtk ls /tmp/rtk-bugtest
# Output: same as above, correct

# Broken:
env -i HOME=$HOME PATH=/opt/homebrew/bin:/usr/bin:/bin \
    LANG=de_DE.UTF-8 rtk ls /tmp/rtk-bugtest
# Output: (empty)
# Exit code: 0

env -i HOME=$HOME PATH=/opt/homebrew/bin:/usr/bin:/bin \
    LANG=fr_FR.UTF-8 rtk ls /tmp/rtk-bugtest
# Output: (empty)
# Exit code: 0

Root Cause Analysis

macOS ls -l produces locale-dependent output:

LANG=en_US.UTF-8: Apr 23 14:55
LANG=de_DE.UTF-8: 23 Apr. 14:55 (different order, period after month abbreviation)
LANG=fr_FR.UTF-8: 23 avril 14:55

File size formatting also differs (e.g. 1.5K vs 1,5K with comma as decimal separator).

rtk's ls output parser appears to only match English-locale formats, resulting in zero parsed entries → (empty) displayed regardless of actual directory contents.

Debug Notes

Other rtk subcommands (rtk git status, rtk git log, etc.) work correctly under all locales — only rtk ls is affected
RUST_BACKTRACE=full produces no output (silent failure)
-vvv flag also produces no debug info
Exit code is always 0, masking the failure from callers

Impact

Affects all users in non-English locales. On macOS, iTerm2's "Set locale environment variables automatically" (the default) propagates the system language as LANG, so any user with a non-English macOS installation hits this. Estimated significant portion of the user base.

Suggested Fix

Spawn the ls subprocess with a forced C/English locale to get parseable, locale-independent output:

Command::new("ls")
    .env("LC_ALL", "C")
    .args(...)
    .output()

This is the same pattern git, cargo, and most locale-sensitive CLI tools use internally. The user's locale is preserved for their own interactive shell; only the tool's internal ls invocation runs in C.

Workaround

Until fixed, users in non-English locales can either:

Change iTerm2 (or their terminal) locale setting to English
Wrap rtk in shell config: rtk() { LC_ALL=en_US.UTF-8 command rtk "$@"; }

wshm · Automated triage by AI

🔍 Automated Triage


🐛 Category	`bug`
🟠 Priority	`high`
🎯 Confidence	96%

Summary

rtk ls parser is hardcoded to English locale output; fix by spawning the ls subprocess with LC_ALL=C — note similarity to #2058 (same empty-output symptom, different trigger)

This looks like a simple fix that could be auto-resolved. Repo maintainers can use /wshm fix to attempt it.

📁 Relevant files

src/commands/ls.rs

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

Using rtk on CachyOS/OpenCode. If anyone is having issues, here is a quick fix using a fish function to set LC_TIME=C:

function rtk
    LC_TIME=C command rtk $argv
end
funcsave rtk

Works perfectly for me!

#1338 on it

Workaround

For affected users, setting LC_ALL=C in Claude Code's settings.json env block scopes the locale override to bash tool calls and restores rtk ls:

{
  "env": {
    "LC_ALL": "C"
  }
}

Verified working

Should be resolved in #1692 aka 0.39.0

@aeppling

hi @aeppling Look like rtk is rely on LANG=C

so Is #1692 work on this ? and 1692 is merged.

for my case #1266 My LANG is zh_CN.UTF-8 so i can close my pr and this issue can be closed ?

@shalk

@shalk Two separate things:

This issue (rtk ls empty on non-English locales) is fixed by #1692 (0.39.0): ls now runs with LC_ALL=C and falls back to raw output on unrecognized locales. Closing.

Your PR #1266 is a different bug. The commit-hash parser in git.rs byte-slices hash[..7], which still panics on [master（根提交） fb597ec] on current develop. The ls locale fix does not cover it, and commit messages and branch names can contain multibyte chars regardless of locale. Please keep #1266 open, I've reviewed it and we want to merge it.

Navigation Menu

Repository navigation

rtk ls returns "(empty)" with non-English locales (LANG=de_DE.UTF-8, fr_FR.UTF-8) #1475

Summary

Environment

Minimal Reproduction

Root Cause Analysis

Debug Notes

Impact

Suggested Fix

Workaround

🔍 Automated Triage

Summary

Workaround

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

rtk ls returns "(empty)" with non-English locales (LANG=de_DE.UTF-8, fr_FR.UTF-8) #1475

Description

Summary

Environment

Minimal Reproduction

Root Cause Analysis

Debug Notes

Impact

Suggested Fix

Workaround

Activity

pszymkowiak commented on Apr 23, 2026

🔍 Automated Triage

Summary

juanlopez87 commented on Apr 23, 2026

aeppling commented on Apr 24, 2026

rushabhpasad commented on Apr 30, 2026

Workaround

aeppling commented on May 6, 2026

shalk commented on May 27, 2026

aeppling commented on Jun 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions