ls (and du) block size specification with thousands separator fails
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 24.1k
- Forks
- 2k
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 365
Description
I just upgraded to Ubuntu 25.10 and got an error with ls:
% /bin/ls --version
/bin/ls (uutils coreutils) 0.2.2
% /bin/ls -l --block-size="1"
total 12288
drwxr-xr-x 22 user user 4096 Oct 26 09:18 documents
drwx------ 3 user user 4096 May 2 21:56 snap
drwxr-xr-x 9 user user 4096 Oct 27 11:33 temp
lrwxrwxrwx 1 user user 14 Oct 2 23:05 tmp -> /run/user/1000
% /bin/ls -l --block-size="'1"
bin/ls: invalid --block-size argument ''1'
% printf "%'d\n" 4096
4,096
According to https://www.gnu.org/software/coreutils/manual/html_node/Block-size.html, the leading quote should add a thousands separator. It's possible that this was being silently ignored before the upgrade and I never noticed, but now it's throwing an error. I have LC_NUMERIC=en_US.UTF-8 and the last printf command shows that's in effect.
du suffers the same, though df appears to work as intended.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the issue with ls and du using --block-size="'1" and LC_NUMERIC=en_US.UTF-8, then compare the behavior with df and GNU coreutils. Trace the command-line block-size parsing and numeric formatting entry points for these utilities. Done means the leading quote is accepted and thousands separators are applied consistently without breaking existing block-size values.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100