rtk-ai/rtk

[BUG] rtk ls parsing relies on POSIX/C locale date ordering and can return false (empty) output

Open

#1652 opened on Apr 30, 2026

View on GitHub
 (3 comments) (0 reactions) (0 assignees)Rust (48,085 stars) (2,914 forks)batch import
bugeffort-smallfilter-qualitygood first issueresolved-pending-close

Description

Summary

rtk ls can return (empty) for a non-empty directory when the underlying ls -la output uses day-month date ordering instead of the POSIX/C locale month-day ordering.

This appears to be because the parser in src/cmds/system/ls.rs assumes dates in the form:

Apr 29 10:42

but my normal shell locale produces:

29 Apr 10:42

When that happens, RTK drops valid lines and emits (empty) instead of either:

  • parsing successfully, or
  • falling back to raw output

Environment

  • RTK version: 0.37.2
  • Install method: Homebrew
  • Binary: /opt/homebrew/bin/rtk
  • Shell: zsh
  • Locale involved: LANG=en_GB.UTF-8

Reproduction

In a non-empty repo:

ls

shows normal output, e.g.

build.rs                   docs                       README_es.md               scripts
Cargo.lock                 Formula                    README_fr.md               SECURITY.md
Cargo.toml                 hooks                      README_ja.md               src
CHANGELOG.md               INSTALL.md                 README_ko.md               tests
CLAUDE.md                  install.sh                 README_zh.md
CONTRIBUTING.md            LICENSE                    README.md
DISCLAIMER.md              openclaw                   release-please-config.json

But RTK returns false empty output:

rtk ls
(empty)

Verbose mode shows that RTK is definitely seeing data and then collapsing it:

rtk -v ls .
Chars: 2072 → 8 (100% reduction)
(empty)

Same for a matching file glob:

rtk -v ls *.sh
Chars: 60 → 8 (87% reduction)
(empty)

Locale-sensitive difference

This appears to depend on the date ordering produced by ls.

With POSIX/C locale:

LC_ALL=C /bin/ls -la .

includes lines like:

-rw-r--r--@   1 donvince  staff  48140 Apr 29 10:42 Cargo.lock

With my normal locale:

LANG=en_GB.UTF-8 /bin/ls -la .

includes lines like:

-rw-r--r--@   1 donvince  staff  48140 29 Apr 10:42 Cargo.lock

And RTK works if I force POSIX/C locale:

LC_ALL=C rtk -v ls .
Chars: 2072 → 552 (74% reduction)
.claude/
.github/
.rtk/
Formula/
docs/
hooks/
openclaw/
scripts/
src/
tests/
.gitignore  503B
.release-please-manifest.json  20B
CHANGELOG.md  76.1K
CLAUDE.md  7.2K
CONTRIBUTING.md  13.9K
Cargo.lock  47.0K
Cargo.toml  1.6K
DISCLAIMER.md  2.2K
INSTALL.md  11.3K
LICENSE  10.5K
README.md  20.6K
README_es.md  5.3K
README_fr.md  6.5K
README_ja.md  5.7K
README_ko.md  5.3K
README_zh.md  5.2K
SECURITY.md  7.3K
build.rs  2.3K
install.sh  2.8K
release-please-config.json  181B

Summary: 20 files, 10 dirs (12 .md, 2 .json, 1 .sh, 1 .toml, 1 no ext, +3 more)
LC_ALL=C rtk -v ls *.sh
Chars: 60 → 51 (15% reduction)
install.sh  2.8K

Summary: 1 files, 0 dirs (1 .sh)

A stripped environment also works:

env -i PATH="/usr/bin:/bin:/opt/homebrew/bin" HOME="$HOME" /opt/homebrew/bin/rtk -v ls .

Expected behavior

rtk ls should not emit false (empty) output for a non-empty directory.

If parsing assumptions do not hold, I would expect RTK to either:

  1. parse the locale-specific ls output correctly, or
  2. fall back to raw output

but not silently suppress valid data.

Likely code path

LC_ALL=C forces the POSIX/C locale and makes rtk ls work. This matches the current parser implementation in src/cmds/system/ls.rs, which explicitly expects month-day date ordering and therefore does not match day-month output like 29 Apr 10:42.

The parser in src/cmds/system/ls.rs appears to anchor on a month-day date shape and does not handle day-month ordering.

Possible fix directions

I’m not attached to a specific implementation, but these seem plausible:

  • force LC_ALL=C for the child ls process to stabilize input format
  • make the parser robust against locale-variant ls date formats (regardless of language and ordering)
  • in any case, avoid returning false (empty) when parsing fails and fall back to raw output instead

Happy to open a PR if maintainers have a preferred direction.

Contributor guide