fix(ls): handle all file types (device, pipe, socket) in ls filter

[MaxenceB59]

Summary

compact_ls only handled regular files (-), symlinks (l), and directories (d). Character devices (c), block devices (b), pipes (p), and sockets (s) were silently dropped, causing rtk ls /dev/ttyACM* to return (empty).

Fix: treat all non-directory file types as files in compact_ls.

Also forces LC_ALL=C on the ls subprocess to ensure consistent date parsing across locales.

Closes #844

Test plan

• Reproduced: rtk ls /dev/ttyp* returned (empty), now lists device files
• Tests added: character devices, block devices, macOS hex device sizes
• All 1675 tests pass (cargo test --all)
• cargo fmt --all && cargo clippy --all-targets clean

[CLAassistant]

All committers have signed the CLA.

[pszymkowiak]

Review approfondie ✅

Deux corrections dans cette PR, toutes deux vérifiées avec le binaire compilé depuis la branche.

Fix 1 — Locale (cmd.env("LC_ALL", "C"))

Subprocess forcé en anglais → mois non-anglais (fr, zh, pt...) n'atteignent plus le parser. Testé avec LC_ALL=fr_FR.UTF-8 rtk ls /tmp/ — les fichiers s'affichent correctement.

Fix 2 — Fichiers device (cause réelle de #844)

/dev/ttyACM* sont des character devices (type c). L'ancien else if file_type == '-' || file_type == 'l' ignorait silencieusement c, b, p, s → (empty). Le else corrige ça.

rtk ls /dev/tty*  →  /dev/tty 0B / /dev/tty0 0B / ...  ✅  (était (empty))

Tests

22/22 passent dont test_compact_device_files, test_compact_device_files_macos_hex_size, test_compact_block_device.

Note mineure

Les device files affichent le numéro mineur comme taille (/dev/tty10 → 10B) — cosmétique, pas une régression.

LGTM

Review incorrecte — voir commentaire de correction ci-dessous

[pszymkowiak]

Thanks for the fix — the core change (else instead of else if '-' || 'l') is the right approach and solves #844. Two things to address before merge.

1. test_compact_device_files_macos_hex_size gives false confidence

The test passes but doesn't verify what is actually displayed. Here is what happens at runtime:

input: crw-rw-rw-  1 root  wheel  0x2000000 Mar 31 19:25 /dev/tty

parse_ls_line size scan (right to left):
  "0x2000000".parse::<u64>()  → Err  (Rust does not parse hex literals)
  "wheel".parse::<u64>()      → Err
  "root".parse::<u64>()       → Err
  "1".parse::<u64>()          → Ok(1)  ← this is the nlink count, not the device id

displayed: /dev/tty  1B   ← wrong

The assert only checks entries.contains("/dev/tty"), so it never catches the 1B coming from the nlink count. The comment says "macOS shows device major/minor as hex" but the test does not verify that this case is handled correctly.

2. Same issue on Linux for non-zero minor numbers

crw-------  1 root  tty  4, 10  Apr 22 09:46 /dev/tty10
  → rightmost parseable number: 10 (the minor device number)
  → displayed: /dev/tty10  10B   ← minor number shown as byte size

Suggested fix

The simplest fix is to make parse_ls_line return size 0 for device files by detecting the major, minor and 0x... formats, or to special-case the size display for non-regular file types. At minimum, the macOS test should assert the full output line so the known limitation is explicit:

// Document what is actually shown (size falls back to nlink count for hex device ids)
assert!(entries.contains("/dev/tty  1B"), "got: {entries}");

The LC_ALL=C change and the else branch are both correct. This is just about making the tests honest about what they cover.

[aeppling]

Hello @MaxenceB59 , the PR description aim to fix #844 , but in your code the LC_ALL affect locales lang, and this was covered by #1338

Could you please ensure focusing on the issue described in #844 ? So we can merge each one separately and cleanly, should be complementary

[aeppling]

Thanks for addressing review @MaxenceB59 , LGTM, merging this for next release

Thank you for contributing to RTK !