bug#23896: ls incorrectly shows quotes when listing file names with spaces

[Pádraig Brady]

On 04/07/16 19:11, Shamim Islam wrote:
> Description of problem:
> Terminal sessions display quotes for files with spaces in them. This is
> non-intuitive behavior. The file name does not have quotes unless quotes
> have been used in the filename. The coreutil ls has been updated to default
> to this new behavior. This behavior should not be foisted on users but
> users should be allowed to choose whether they want to OPT IN. Debian and
> Ubuntu distros have already reverted.
> 
> 
> Version-Release number of selected component (if applicable):
> coreutils-8.25-5.fc24.x86_64
> 
> 
> How reproducible:
> Fresh install of Fedora 24. All the time.
> 
> 
> Steps to Reproduce:
> 1. > "File with spaces.txt"
> 2. ls
> 
> Actual results:
> 'File with spaces.txt'
> 
> Expected results:
> File with spaces.txt
> 
> Additional info:
> This is a core expectation. The filename we see should be the same as the
> filename in use.

Ideally yes.
However there are lots of cases where this is already not the case.
I.E. ls already only showed a representation of the real name,
with ? being shown for certain characters etc.
By using the current format, the output from ls can now always be copy/pasted 
to other commands.
Also using quotes can disambiguate files with spaces when listed 'side by' side.
Also quotes help protect users from copy and pasting dangerous file names.

> We do not require additional tools to help us identify
> what is a complete filename and what is not. ESPECIALLY in the terminal
> session where the user is expected to be versant in POSIX. If the user
> needs hand-holding, they can use the GUI tools like Dolphin or Konqueror.
> Note - neither of these tools shows 'quotes' around files with space in the
> name. Neither does Windows. Neither does Mac OS.
> 
> Please revert. Please instruct coreutils developers to revert. Please set
> any defaults required to not show the quotes. The user should not have to
> discover there is no error.
> 
> E.g. I downloaded an MP3 file today with spaces. I saw the single quotes
> and immediately thought there was a problem in firefox naming the file on
> download.
> 
> This is insane.

I can't see any argument from you for _why_ this should be changed back.
As far as I can see, this didn't cause an actual functional issue for you.
You just weren't expecting the change.  We did carefully consider the change,
and the reason we set that default was to have the safer and less ambiguous
output used by default.  Changing back to the previous behavior is just a
matter of adding -N to your ls alias which shouldn't be too onerous.

thanks,
Pádraig.