GNU bug report logs -
#53025
Encouragement to go back to *dis*abled quotation marks in ls output as *default* behavior
Previous Next
To reply to this bug, email your comments to 53025 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#53025
; Package
coreutils
.
(Wed, 05 Jan 2022 15:57:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Joerg M. Sigle" <joerg.sigle <at> jsigle.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Wed, 05 Jan 2022 15:57:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Dear coreutils developers
Thank you very much for your efferts in trying to provide and maintain
fine tools that help millions or billions of users every day.
I'm one who appreciates that (and I try to do something similar as well).
Still, sometimes there have been changes introduced over the years,
that may have been well intended, but still do more harm than good,
even if not visible to everyone at first glance.
Introduction of quotation marks placed selectively around ls output
containing spaces is an example for that.
I'd like to encourage you to make this behaviour an option again,
and put the default setting back to leaving these quotation marks away.
Whoever wants them, can activate them - and who doesn't, won't be
bothered by an inconsistent and somewhat annoying behavior that disrupts
the visual processing of every single ls output where it becomes apparent -
and requires the addition of an option line for every single existing(!)
.bashrc file on systems where the "new" behaviour is not desired.
And, given the change was introduced in 2016, and re-introduced in 2019,
and annoyance is still caused in 2021 - well, whenever it has been fixed
in existing systems, the problem still turns up in each and every newly
set up system since then, in a delayed manner because naturally ls output
with spaces is not the first thing that will appear, and therefore requires
a lookup of its cause and remedy, and then the manual addition of fixes to
each already existing user account set up until then.
As somebody put it on publicly available pages:
"When this many people consider a thing a bug, then it's a bug whether maintainers disagree or not."
Quoted from:
https://unix.stackexchange.com/questions/258679/why-is-ls-suddenly-wrapping-items-with-spaces-in-single-quotes/262162#262162
The bigger problem is, that it's not only ls which is affected like that.
Similar changes, instead, occur in more and more places - in browsers, in
the X11 environment (now even losing it's network transparency etc.), in the
design of GUIs with inconsistant apprance and unrecognizable operating elements
and so on. It's like if somebody has a bad idea, they're not held back by
traditions or established standards or knowledgeable people around them any more -
but on the contrary, that bad idea is immediately implemented, distributed, and
then: even copied over and over by other people who think things must constantly
be "renewed" even if the existing version was perfect and simple, and "new" usually
means "more complex" and "obviously worse".
Anyway. Thank you very much for consideration of this message,
including its philosophical background, and kind regards!
Joerg
--
-------------------------------------------------------------------
Dr. med. Jörg M. Sigle +41 76 276 86 94
http://www.ql-recorder.com +41 32 510 23 46
http://www.jsigle.com +49 176 96 43 54 13
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#53025
; Package
coreutils
.
(Wed, 05 Jan 2022 16:49:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 53025 <at> debbugs.gnu.org (full text, mbox):
On 05/01/2022 08:44, Joerg M. Sigle wrote:
> Dear coreutils developers
>
> Thank you very much for your efferts in trying to provide and maintain
> fine tools that help millions or billions of users every day.
> I'm one who appreciates that (and I try to do something similar as well).
>
> Still, sometimes there have been changes introduced over the years,
> that may have been well intended, but still do more harm than good,
> even if not visible to everyone at first glance.
>
> Introduction of quotation marks placed selectively around ls output
> containing spaces is an example for that.
>
> I'd like to encourage you to make this behaviour an option again,
> and put the default setting back to leaving these quotation marks away.
> Whoever wants them, can activate them - and who doesn't, won't be
> bothered by an inconsistent and somewhat annoying behavior that disrupts
> the visual processing of every single ls output where it becomes apparent -
> and requires the addition of an option line for every single existing(!)
> .bashrc file on systems where the "new" behaviour is not desired.
>
> And, given the change was introduced in 2016, and re-introduced in 2019,
> and annoyance is still caused in 2021 - well, whenever it has been fixed
> in existing systems, the problem still turns up in each and every newly
> set up system since then, in a delayed manner because naturally ls output
> with spaces is not the first thing that will appear, and therefore requires
> a lookup of its cause and remedy, and then the manual addition of fixes to
> each already existing user account set up until then.
upstream has been consistent in maintaining the behavior since it was introduced.
>
> As somebody put it on publicly available pages:
>
> "When this many people consider a thing a bug, then it's a bug whether maintainers disagree or not."
> Quoted from:
>
> https://unix.stackexchange.com/questions/258679/why-is-ls-suddenly-wrapping-items-with-spaces-in-single-quotes/262162#262162
>
>
> The bigger problem is, that it's not only ls which is affected like that.
> Similar changes, instead, occur in more and more places - in browsers, in
> the X11 environment (now even losing it's network transparency etc.), in the
> design of GUIs with inconsistant apprance and unrecognizable operating elements
> and so on. It's like if somebody has a bad idea, they're not held back by
> traditions or established standards or knowledgeable people around them any more -
> but on the contrary, that bad idea is immediately implemented, distributed, and
> then: even copied over and over by other people who think things must constantly
> be "renewed" even if the existing version was perfect and simple, and "new" usually
> means "more complex" and "obviously worse".
>
> Anyway. Thank you very much for consideration of this message,
> including its philosophical background, and kind regards!
Reasoning for the default behavior is detailed at:
https://www.gnu.org/software/coreutils/quotes.html
thanks,
Pádraig.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#53025
; Package
coreutils
.
(Wed, 05 Jan 2022 20:48:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 53025 <at> debbugs.gnu.org (full text, mbox):
On 1/5/22 00:44, Joerg M. Sigle wrote:
> "When this many people consider a thing a bug, then it's a bug whether maintainers disagree or not."
By that standard it'll be a bug no matter what the maintainers do, since
feelings are strong on both sides of the issue. So by this reasoning,
maintainers might as well do nothing.
In the meantime you can avoid the issue yourself by using this:
alias ls="ls -N"
in your .profile or whatever.
Severity set to 'wishlist' from 'normal'
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org
.
(Wed, 05 Jan 2022 20:49:02 GMT)
Full text and
rfc822 format available.
Added tag(s) notabug.
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org
.
(Wed, 05 Jan 2022 20:49:02 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 164 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.