[ryana-0154]

Summary

• Fixes The result of rtk ls -la is equivalent to rtk ls, which leads to the loss of some info. #1672 — rtk ls -la was producing output identical to rtk ls because the filter stripped permission/ownership entirely.
• When the user passes -l (or -la), each entry is now prefixed with octal perms (e.g. 644, 755), matching the proposal in the issue.
• Special bits (setuid/setgid/sticky) emit a 4-digit form (4755, 1777, 7777).
• rtk ls (no -l) is unchanged.

Example

Before:
.DS_Store 6.0K
init.py 984B

After (rtk ls -la):
644 .DS_Store 6.0K
644 init.py 984B

Test plan

• cargo fmt --all -- --check
• cargo clippy --all-targets — 0 errors (pre-existing warnings unchanged)
• cargo test --all — 1692 passed, 6 ignored
• New unit tests for perms_to_octal (common perms, setuid/setgid/sticky, garbage input) and for long vs. short output formatting

[pszymkowiak]

[w] wshm · Automated triage by AI

📊 Automated PR Analysis

🐛 Type	bug-fix
🟢 Risk	low

Summary

Fixes the rtk ls -la command which was producing output identical to rtk ls by preserving permission information as octal notation when -l is passed. Adds a perms_to_octal function to convert ls-style permission strings to octal format, handling special bits (setuid/setgid/sticky) with a 4-digit form. Existing rtk ls behavior without -l is unchanged.

Review Checklist

• Tests present
• Breaking change
• Docs updated

Linked issues: #1672

---

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

[KuSh]

Thanks for the PR, that's a great addition but it needs some minor changes first!

[KuSh]

Thanks for the PR, that's a great addition but it needs some minor changes first!

[KuSh]

Hi @ryana-0154, you'll need to resolve conflicts before we can merge that one, otherwise LGTM!

[ryana-0154]

Hi @ryana-0154, you'll need to resolve conflicts before we can merge that one, otherwise LGTM!

Hi - there doesn't seem to be any merge conflicts to develop - can you confirm?

[KuSh]

Hi @ryana-0154, you'll need to resolve conflicts before we can merge that one, otherwise LGTM!

Hi - there doesn't seem to be any merge conflicts to develop - can you confirm?

Let me recheck, I did have one when I tried earlier

[KuSh]

@ryana-0154 there's a conflict, please rebase:

❯ git rebase upstream/develop
Auto-merging src/cmds/system/ls.rs
CONFLICT (content): Merge conflict in src/cmds/system/ls.rs
error: could not apply 39dee40... fix(ls): preserve permission info as octal when -l/-la is passed
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Could not apply 39dee40... # fix(ls): preserve permission info as octal when -l/-la is passed

[CLAassistant]

All committers have signed the CLA.

[KuSh]

You seem to have rebased on the wrong branch (certainly master) you have to fix that. 57 files changed all over the place is too much for the subject 😉

[ryana-0154]

You seem to have rebased on the wrong branch (certainly master) you have to fix that. 57 files changed all over the place is too much for the subject 😉

duh... what an idiot :D Fixed!