GNU bug report logs - #23896
ls-quotes: ls incorrectly shows quotes when listing file

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23896 in the body.
You can then email your comments to 23896 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Shamim Islam <shamim.islam <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: ls incorrectly shows quotes when listing file names with spaces
Date: Mon, 4 Jul 2016 14:11:05 -0400

[Message part 1 (text/plain, inline)]

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. 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.

[Message part 2 (text/html, inline)]

Message #8 received at 23896 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Shamim Islam <shamim.islam <at> gmail.com>, 23896 <at> debbugs.gnu.org
Subject: Re: bug#23896: ls incorrectly shows quotes when listing file names
 with spaces
Date: Mon, 4 Jul 2016 21:19:01 +0100

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.

Message #11 received at 23896 <at> debbugs.gnu.org (full text, mbox):

From: Ruediger Meier <sweet_f_a <at> gmx.de>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: Shamim Islam <shamim.islam <at> gmail.com>, 23896 <at> debbugs.gnu.org
Subject: Re: bug#23896: ls incorrectly shows quotes when listing file names
 with spaces
Date: Tue, 5 Jul 2016 11:20:42 +0200

On Monday 04 July 2016, Pádraig Brady wrote:
> 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.

Because coreutils' ls is now the only existing ls which behaves that 
stupid. Any GUI filebrowser or whatever other program would show the 
file name as is. Just coreutils ls will print something else...

People who add spaces or whatever strange characters to their file names 
probably want to _see_ these "nice looking file names". Adding strange 
escape sequences and quotes is most likely not what they want to see.

> 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. 

You added a new kind of quoting style and even enabled it by default 
within the same patch-set. No user on earth was able to test the new 
quoting style nor anybody had asked you to make it the default. I don't 
see that it was "carefully considered".

> Changing back to the previous behavior is just a matter of adding -N
> to your ls alias which shouldn't be too onerous.

It would be also no problem to add the quoting style to the alias if 
wanted. Personally I use it manually, only when needed, but this case 
happens not more than 2-3 times per year.


cu,
RUdi

Message #18 received at 23896-done <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Ruediger Meier <sweet_f_a <at> gmx.de>
Cc: Shamim Islam <shamim.islam <at> gmail.com>, 23896-done <at> debbugs.gnu.org
Subject: Re: bug#23896: ls incorrectly shows quotes when listing file names
 with spaces
Date: Thu, 13 Dec 2018 13:25:22 -0700

Hello,

On 2016-07-05 3:20 a.m., Ruediger Meier wrote:
> On Monday 04 July 2016, Pádraig Brady wrote:
>> 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.
>>>

We created a summary of common issues and FAQs
regarding the quoting change in ls(1):
  https://www.gnu.org/software/coreutils/quotes.html

If there is an issue that is not addressed there,
please send an email to coreutils <at> gnu.org .

regards,
 - assaf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.