GNU bug report logs - #53025
Encouragement to go back to *dis*abled quotation marks in ls output as *default* behavior

Previous Next

Full log

View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: "Joerg M. Sigle" <joerg.sigle <at> jsigle.com>, 53025 <at> debbugs.gnu.org
Subject: bug#53025: Encouragement to go back to *dis*abled quotation marks in ls output as *default* behavior
Date: Wed, 5 Jan 2022 16:48:42 +0000

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.

Previous Next

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