This post was last updated 5 years 10 months 8 days ago, some of the information contained here may no longer be actual and any referenced software versions may have been updated!Don’t panic.
Coretutils 8.25+ adds single quotes to filenames containing spaces when listed with ls
ls -al
-rw-r–r– 1 root root 0 May 14 11:41 ‘file with spaces’
When you first see this you may think “WTF has happened to my files” – stay frosty :
- It was introduced in coreutils v8.25, and alignment improved in v8.26
- It only happens when outputting to terminals so doesn’t break scripts
- It disambiguates the output for users for files containing whitespace
- It sanitizes output so it is safe to copy and paste
- Output is now always valid to copy and paste back to shell
- you can get back to the old format by adding -N to the ls alias or set export QUOTING_STYLE=literal in your .bashrc
And relax – all is well…
The same is true if the filename contains “=”:
11:02> ls my*.txt
‘my=file.txt’
This BS changes breaks 45+ years of Unix tradition, and the Principle of Least Surprise. “If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature.”
I’m 56 years old and have been using Unix (and almost every derivative) since I was 16 — that’s 40 years. I’m OK with this change. it’s only a feature of ls(1) and it doesn’t wrap the filename in quotes if stdout is not a tty. Seems like nothing breaks here.
I have seen long filenames with spaces in them in ls output where I could not tell where the filename started and stopped (because of the column output or wide output format that I used at the time). So I switched to ‘ls -l’ to get the long format and I can see then, but it was an additional step that this change makes unnecessary now. I see this as a good change.
This is puzzling, useless and breaks uniformity across different distros