#23896 - ls-quotes: ls incorrectly shows quotes when listing file (original) (raw)
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.
Report forwardedto bug-coreutils <at> gnu.org:bug#23896; Package coreutils. (Mon, 04 Jul 2016 18:30:02 GMT) Full text and rfc822 format available.
Acknowledgement sentto Shamim Islam <shamim.islam <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Mon, 04 Jul 2016 18:30:02 GMT) Full text and rfc822 format available.
Message #5 received at submit debbugs.gnu.org (full text, mbox):
[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:
"File with spaces.txt"
- 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)]
Information forwardedto bug-coreutils <at> gnu.org:bug#23896; Package coreutils. (Mon, 04 Jul 2016 20:20:01 GMT) Full text and rfc822 format available.
Message #8 received at 23896 debbugs.gnu.org (full text, mbox):
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:
"File with spaces.txt"
- 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.
Information forwardedto bug-coreutils <at> gnu.org:bug#23896; Package coreutils. (Tue, 05 Jul 2016 09:21:02 GMT) Full text and rfc822 format available.
Message #11 received at 23896 debbugs.gnu.org (full text, mbox):
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:
"File with spaces.txt"
- 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
**Changed bug title to 'ls-quotes: ls incorrectly shows quotes when listing file' from 'ls incorrectly shows quotes when listing file names with spaces'**Request was from Assaf Gordon <assafgordon <at> gmail.com>to control <at> debbugs.gnu.org. (Sun, 28 Oct 2018 06:22:02 GMT) Full text and rfc822 format available.
Reply sentto Assaf Gordon <assafgordon <at> gmail.com>:
You have taken responsibility. (Thu, 13 Dec 2018 20:26:02 GMT) Full text and rfc822 format available.
Notification sentto Shamim Islam <shamim.islam <at> gmail.com>:
bug acknowledged by developer. (Thu, 13 Dec 2018 20:26:02 GMT) Full text and rfc822 format available.
Message #18 received at 23896-done debbugs.gnu.org (full text, mbox):
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 gnu.org .
regards,
- assaf
**bug archived.**Request was from Debbugs Internal Request <help-debbugs <at> gnu.org>to internal_control <at> debbugs.gnu.org. (Fri, 11 Jan 2019 12:24:10 GMT) Full text and rfc822 format available.
This bug report was last modified 6 years and 155 days ago.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.