Skip to content

rtk ls -1 returns empty output unconditionally #3527

Closed
Closed
rtk ls -1 returns empty output unconditionally#3527
Labels
area:clibugSomething isn't workingpriority:highresolved-pending-closeAnswered/resolved — will close if no response

Description

@ReeveBarthelme
ReeveBarthelme
opened on Aug 10, 2026

Summary

rtk ls -1 produces zero output in every invocation mode I tested — not TTY-dependent, unconditional.

Repro

$ mkdir /tmp/repro && cd /tmp/repro && touch a.txt b.txt

$ rtk ls
a.txt  0B
b.txt  0B

2 files, 0 dirs (2 .txt)

$ rtk ls -a
a.txt  0B
b.txt  0B

2 files, 0 dirs (2 .txt)

$ rtk ls -l
a.txt  0B
b.txt  0B

2 files, 0 dirs (2 .txt)

$ rtk ls -1
(no output, exit 0)

$ rtk ls -1 | cat
(no output, exit 0)

$ rtk ls -1 > out.txt 2>&1; cat out.txt
(empty file)

rtk --version: 0.34.1 (Mach-O 64-bit arm64, macOS)

Notes

  • -a and -l both work fine and produce the normal compact summary — only -1 (one-per-line) is affected.
  • Not a TTY-detection issue: bare, piped, and file-redirected calls are all equally empty.
  • Found while auditing Claude Code hook rewrite coverage — rtk rewrite "ls -1" correctly emits rtk ls -1, so the hook silently routes any raw ls -1 into this empty-output path with no error surfaced to the caller.

Activity

  1. pszymkowiak
    added
    area:cli
    bugSomething isn't working
    priority:high
    on Aug 10, 2026

  2. pszymkowiak commented on Aug 10, 2026

    @pszymkowiak
    pszymkowiak
    on Aug 10, 2026
    Collaborator

    wshm · Automated triage by AI

    🔍 Automated Triage
    🐛 Category bug
    🟠 Priority high
    🎯 Confidence 90%

    Summary

    rtk ls -1 (one-per-line output) produces empty output in all invocation modes; recommend fixing the output formatter for the -1 flag and surfacing an error rather than silently succeeding.

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

    📁 Relevant files
    • src/ls.rs

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

  3. davidalecrim1 commented on Aug 11, 2026

    @davidalecrim1
    davidalecrim1
    on Aug 11, 2026
    Contributor

    @ReeveBarthelme Can you update RTK and try again? I tested this out on the version 0.43.0 and it works for me in MacOS:

    ❯ mkdir /tmp/repro && cd /tmp/repro && touch a.txt b.txt
❯ ls -1
a.txt
b.txt
❯ ls
a.txt b.txt
❯ ls -1
a.txt
b.txt
❯ rtk ls
a.txt  0B
b.txt  0B

Summary: 2 files, 0 dirs (2 .txt)
❯ rtk ls -1
.
..
a.txt
b.txt
❯ rtk --version
rtk 0.43.0

  4. ReeveBarthelme commented on Aug 12, 2026

    @ReeveBarthelme
    ReeveBarthelme
    on Aug 12, 2026
    Author

    Confirmed fixed — thanks @davidalecrim1. Reproduced the before/after side by side on macOS (aarch64):

    $ mkdir -p /tmp/repro && cd /tmp/repro && touch a.txt b.txt

# 0.34.1 (the version in the report)
$ rtk ls -1
(no output, exit 0)

# 0.45.0
$ rtk ls -1
.
..
a.txt
b.txt
$ rtk ls -1 | cat
.
..
a.txt
b.txt

    Empty-output bug is gone in 0.45.0 in both bare and piped modes, so this can be closed.

    One follow-up worth a separate look, and I've corrected an earlier version of this comment where I described it imprecisely. On a real repo checkout, -1 does not just change the layout — it changes the entry set two ways:

    $ rtk ls    | <extract names> | sort -u | wc -l     # 158
$ rtk ls -1 | <extract names> | sort -u | wc -l     # 168
$ ls -1A                      | sort -u | wc -l     # 166   (system ls, BSD)

# the 10 entries `rtk ls -1` has that `rtk ls` does not:
.  ..  .DS_Store  .git  .mypy_cache  .pytest_cache  .venv  .vscode  __pycache__  node_modules

    So -1 (a) emits . and .., which GNU/BSD ls -1 never does, and (b) bypasses the noise filter that plain rtk ls applies to VCS/build/cache dirs. Plain rtk ls does still show ordinary dotfiles like .gitignore, so this isn't simply -1 implying -a — it's a different entry set from both rtk ls and system ls. That will surprise anything piping it into xargs/wc -l. Happy to file it as its own issue if useful.

  5. KuSh commented on Sep 12, 2026

    @KuSh
    KuSh
    on Sep 12, 2026
    Collaborator

    Fixed on develop, not yet in a release — labelling resolved-pending-close rather than closing.

    Re-ran the repro against a build of current develop (8b891a5c), LC_ALL=C:

    $ mkdir -p /tmp/repro && cd /tmp/repro && touch visible.txt .hidden
$ rtk ls -1
visible.txt  0B
[exit 0]

    Output is present, so the unconditional-empty behaviour is gone.

  6. KuSh
    added
    resolved-pending-closeAnswered/resolved — will close if no response
    on Sep 12, 2026

  7. KuSh commented on Sep 13, 2026

    @KuSh
    KuSh
    on Sep 13, 2026
    Collaborator

    This is fixed. rtk ls -1 prints the listing again in bare, piped and redirected forms, confirmed on the current code, and the follow-up you noted (-1 emitting ./.. and bypassing the noise filter) is fixed as well by the dotfile-semantics change shipped in v0.49.0. If you still see empty output on the latest version, comment here and we will reopen.

  8. KuSh
    closed this as completedon Sep 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:clibugSomething isn't workingpriority:highresolved-pending-closeAnswered/resolved — will close if no response

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions