246

I just noticed that on one of my machines (running Debian Sid) whenever I type ls any file name with spaces has single quotes surrounding it.

I immediately checked my aliases, only to find them intact.

wyatt@debian630:~/testdir$ ls
'test 1.txt'  test1.txt
wyatt@debian630:~/testdir$ alias
alias ls='ls --color=auto'
alias wget='wget --content-disposition'
wyatt@debian630:~/testdir$

(picture)

Another test, with files containing single quotes in their names (also answering a request by jimmij):

wyatt@debian630:~/testdir$ ls
'test 1.txt'  test1.txt  'thishasasinglequotehere'\''.txt'
wyatt@debian630:~/testdir$ touch "'test 1.txt'"
wyatt@debian630:~/testdir$ ls
''\''test 1.txt'\'''  test1.txt
'test 1.txt'          'thishasasinglequotehere'\''.txt'

(picture)

update with new coreutils-8.26 output (which is admittedly much less confusing, but still irritating to have by default). Thanks to Pádraig Brady for this printout:

$ ls
"'test 1.txt'"   test1.txt
'test 1.txt'    "thishasasinglequotehere'.txt"

$ ls -N
'test 1.txt'  test1.txt
test 1.txt    thishasasinglequotehere'.txt

Why is this happening? How do I stop it properly?

To be clear, I myself set ls to automatically color output. It just never put quotes around things before.

I'm running bash and coreutils 8.25.

Any way to fix this without a recompile?

EDIT: Appears the coreutils developers chose) to break with the convention and make this the global default.

UPDATE - October 2017 - Debian Sid has re-enabled the shell escape quoting by default. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877582

And at the bottom of the reply chain to the previous bug report, "the change was intentional and will remain." https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813164#226

I thought this had already been settled, but apparently it was just reverted so that the "stable" Debian branch could keep its "feature freeze" while getting the other fixes, etc. from the newer version. So that's a shame (in my opinion).

UPDATE: April 2019: Just found a spurious bug report in PHP that was caused by this change to ls. When you're confusing developers and generating false bug reports, I think it might be time to re-evaluate your changes.

Update: Android toybox ls is now doing something similar to this but with backslashes instead of quotes. Using the -q option makes spaces render as 'question mark characters' (I have not checked what they are, since they're obviously not spaces), so the only fix I have found so far without rooting the device in question is to add this to a script and source it when launching a shell. This function makes ls use columns if in a terminal and otherwise print one-per-line, while tricking ls into printing spaces verbatim because it's running through a pipe.

ls() {
    # only way I can stop ls from escaping with backslashes
    if [ -t 1 ]; then
        /system/bin/ls -C $@ |cat
    else
        /system/bin/ls $@ |cat
    fi
}
Wyatt Ward
  • 4,032
  • 24
    Yet another reason why not parser the ls command. – jimmij Jan 30 '16 at 07:27
  • 1
    jimmij: personally I don't use ls for parsing, but I am sure someone does. This is just irritating (added a second pic) and very confusing when you're looking at a file listing. Wil add another with yours. – Wyatt Ward Jan 30 '16 at 07:32
  • 1
    @Wyatt8740: I don't think it break any *nix tradition, the quoting style is not defined by POSIX standard. – cuonglm Jan 30 '16 at 07:44
  • 16
    It looks odd but if it's only enabled when printing to a terminal it makes sense. You can see clearly that you have a file 'test 1.txt' rather than a file 'test' and another '1.txt'. Try ls | cat and see if it goes away. If I had a time machine, I would go back to Bell Labs ~1970 and try to convince Ken Thompson that allowing space in file and directory names is a bad idea. :-P – Bjorn Munch Jan 30 '16 at 09:06
  • @cuonglm Point taken, but traditional ls in System V (and the BSD's) never did this. – Wyatt Ward Jan 30 '16 at 16:06
  • 1
    Of course, BSD ls outputs non-ASCII bytes as '?' if output is to the terminal, with no option to disable it. – Mark Plotnick Jan 30 '16 at 19:30
  • @MarkPlotnick that happens to me with GNU ls in some environments, too. That's hardly unique. Wish I could figure out why it does it, though. – Wyatt Ward Jan 31 '16 at 00:03
  • 7
    When I first saw this, I freaked out, thinking that one of my scripts had gone awry and renamed all my files to '*'. I guess I'll go around adding ls aliases to all my machines to get rid of it... – lmat - Reinstate Monica Feb 12 '16 at 18:57
  • 16
    @LimitedAtonement, as pointed out by Lekensteyn, you can do this with an environment variable QUOTING_STYLE=literal rather than an alias. (I guess it's a matter of taste, but I prefer the variable.) – LSpice Feb 15 '16 at 23:15
  • @LSpice I just added to my existing aliases: l='ls -CFN', ll='ls -alFN', etc. – lmat - Reinstate Monica Feb 16 '16 at 01:44
  • 3
    @LimitedAtonement, sure, but fixing one environment variable will cover all the aliases automatically, and then you can always add get the new default (or other) behaviour by overriding the environment variable with l --quoting=shell-escape (or other quoting style). – LSpice Feb 16 '16 at 03:35
  • 5
    @BjornMunch there are two solutions to the issue of telling whether it is one file or two: 1) look for how the columns are being drawn and it is fairly obvious. 2) list one item per line. Both of those look better and clearer than the mangling with single quotes. – Wyatt Ward Feb 23 '16 at 14:52
  • 3
    @jimmij Your comment is off-topic. First off because you don't answer the OP's question(s). Second because the new ls behaviour does not break scripts that parse ls. Check ls -l | less . –  May 26 '16 at 13:28
  • 1
    Images of text are hard to read by blind people, please just paste the text. – ctrl-alt-delor Jan 16 '17 at 13:16
  • @richard sorry. When I posted this I was not aware of that rule. I don't have access to a unix machine with this version of coreutils at the moment, but I will attempt to do a dump from one when next I have a chance. – Wyatt Ward Jan 19 '17 at 00:32
  • 3
    just deployed a new VPS with Ubuntu 18 and to my horror this has still not gone away. Why, why? Why? I've read nearly every comment and answer here and still have no satisfactory answer to that question. – Eaten by a Grue May 03 '18 at 02:52
  • 2
    @billynoah change for change's sake I guess. Drives me absolutely crazy, too. – Wyatt Ward May 04 '18 at 16:41
  • 3
    I love having to come back to this question to remember what the magic variable name is to get ls to act normal. Can't stop progress, I suppose. – David Dombrowsky Sep 17 '18 at 20:16
  • 1
    Breaks Emacs dired mode badly. – rptb1 Sep 19 '18 at 14:52
  • 1
    @rptb1 haha, funny how they will break another GNU project's code while still claiming 'It only happens when outputting to terminals so doesn't break scripts.' Not technically incorrect since emacs probably is acting as a terminal, but funny nonetheless – Wyatt Ward Sep 24 '18 at 15:01
  • 4
    I died a little inside after thinking I was losing my mind and my files had quotes in them for about two hours, then coming here and reading the explanation. Ugh. – Jazzepi Oct 23 '18 at 15:40

3 Answers3

156

Preface: While it may be quite satisfying to upvote an answer such as this and call it a day, please be assured that the GNU coreutils maintainers do not care about SO answer votes, & that if you actually want to encourage them to change, you need to email them as this answer describes.

Update 2019:
Sometime this past year the maintainers have doubled-down and now offer to any bug-coreutils@gnu.org reports about this issue only a boilerplate response pointing to an incredibly long page on their website listing problems people have with this change that they have committed themselves to ignoring.
The unceasing pressure from bug-coreutils@gnu.org reports has clearly had an effect, forcing the generation of this immense & absurd page, and potentially reducing the number of maintainers willing to deal with the problem to only one.
When this many people consider a thing a bug, then it's a bug whether maintainers disagree or not.
Continuing to email them remains the simplest way to encourage change.

"Why is this happening?"

Several coreutils maintainers decided they knew better than decades of de facto standards.

"How do I stop it properly?"

http://www.gnu.org/software/coreutils/coreutils.html:

Bug Reports

If you think you have found a bug in Coreutils, then please send as complete a bug report as possible to <bug-coreutils@gnu.org>, and it will automatically be entered into the Coreutils bug tracker. Before reporting bugs please read the FAQ. A very useful and often referenced guide on how to write bug reports and ask good questions is the document How To Ask Questions The Smart Way . You can browse previous postings and search the bug-coreutils archive.

Distros that have already reverted this change:

Distros unaffected:

  • openSUSE (already used -N)

"Any way to fix this without a recompile?"

Proponents would have you...

get back to the old format by adding -N to their ls alias

…on all of your installs, everywhere, for the remainder of eternity.

Jan Kyu Peblik
  • 1,829
  • 2
    Source needed for that claim about the developer. – muru Feb 14 '16 at 09:52
  • 1
    @muru: This? http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=109b9220cead6e979d22d16327c4d9f8350431cc;hp=5ef08864113505c6392158c9fac9a6cb1b3ac0e6 – Piskvor left the building Feb 15 '16 at 11:36
  • 20
    The change was proposed on the mailing list and agreed by three coreutils maintainers to be a net benefit. We're entirely open to constructive arguments about this. This is open source after all, we don't mean to dictate, only to improve things. Please feel free to respond in the coreutils thread at http://lists.gnu.org/archive/html/coreutils/2016-02/msg00000.html (BTW the way, there was a constructive suggestion to improve on one of the aesthetic disadvantages mentioned there, by adding a space to improve alignment) – Pádraig Brady Feb 15 '16 at 20:46
  • 1
    @Pádraig-Brady I see you posted early in the debian bug report (in the mailing list) about this, but want to ask if you've seen the followups since then. I see a lot of negative feedback there too (though I suppose people happy with it don't generally say much). – Wyatt Ward Feb 16 '16 at 02:02
  • 43
    @PádraigBrady Updated answer. Seeing loads of denial in your coreutils thread, though. The bottom line is you are creating more work for people, and you're doing it in the name of an OS that is a clone of an OS from 1970. If people want something different, they will opt into it. – Jan Kyu Peblik Feb 17 '16 at 22:21
  • 53
    @PádraigBrady This change has caused me annoyance and wasted several hours trying find a cause and a solution. I don't mean to be negative - I'm just sharing another persons viewpoint! Modifying core behaviour has huge implications.. – mafrosis Mar 16 '16 at 16:15
  • 67
    As someone who's used *nix systems for 30 years, I find gratuitous changes like this to be quite annoying. They break long-standing scripts, for one thing. They also violate the Principle of Least Astonishment. "Opt-in" should've been the default here, as noted above. – Brian Clapper Apr 07 '16 at 00:01
  • 34
    @PádraigBrady That's still not the way to push such changes. It'd have been way more constructive to have that behaviour opt-in instead of active by default. It also falsely hints this is how file names are stored, in short with ls what you see no longer is how it's stored. That feature should be optional, not the default. –  May 26 '16 at 13:19
  • 3
    @JanKyuPeblik the distros that haven't reverted this change include Gentoo and (if it counts) Cygwin. Also presumably Red Hat (since Cygwin is managed by people at Red Hat). Not sure if you want to add them to your list or not. – Wyatt Ward Jul 24 '16 at 05:36
  • 2
    Does anyone know if there's an active bug about this change in the coreutils tracker? Is there a sensible way to disagree with this changed default? – Honore Doktorr Jul 26 '16 at 19:51
  • 1
    @HonoreDoktorr This answer explains the sensible way. We can hope that eventually upstream will relent. Please do not mistake upstream discussion on this matter here as being equivalent to (courteous) complaining directly to upstream, however. – Jan Kyu Peblik Aug 15 '16 at 03:50
  • 2
    @Wyatt8740 Since it affects all distros (even those sensible enough to have avoided it so far), I think it's simplest to only list those with less to worry about. – Jan Kyu Peblik Aug 15 '16 at 03:50
  • 8
    I wasted hours trying to rename those damn files with regex.... – Jin Kwon Oct 22 '16 at 16:38
  • 7
    @BrianClapper "They break long-standing scripts, for one thing." – I don't like this change either, but why are you even parsing the output of ls in a script in the first place? Also, no, it doesn't break scripts, because it only does this when outputting to a terminal. – Alexia Luna Jun 30 '17 at 10:57
  • 1
    Hey, @JanKyuPeblik - I wanted to give you an update. Debian is no longer reverting this change (current Debian Sid has quoting enabled by default). – Wyatt Ward Nov 20 '17 at 18:07
  • 2
    @Wyatt8740 My condolences. Text updated. I'm pretty ambivalent about his use of the word 'ambivalent' when he probably meant 'indifferent', and generally about why a person in public service would operate from a standpoint of indifference ever; that being roughly the opposite of the point, IMO. – Jan Kyu Peblik Nov 24 '17 at 00:47
  • @BrianClapper "why are you" should highlight the you ... because we ALL use scripts we didn't write. – Philip Couling Jan 31 '18 at 12:44
  • 2
    Thanks for updating this with the urge to email the bug tracker. This is going to drive me insane if it's not reverted. – Wyatt Ward Jan 31 '18 at 22:18
  • 1
    @Francisco truly objectively funny (because of the truth of it). :p I don't actually blame distro maintainers for not wanting to take on the burden of more maintenance (even though they all do a lot, & in this particular case it's a trivial one), but the way Debian flips is confusing; did the same thing with ffmpeg. Might hope they'll similarly come to senses in this situation. Meanwhile, ppl should talk to coreutils & distros directly to get anywhere. Could also just fork coreutils for the purpose of being less lame maintainers & others might just adopt it; happened with glibc->eglibc IIRC. – Jan Kyu Peblik Apr 23 '18 at 19:35
  • 4
    I don't blame the distro maintainers, I actually commend them for dealing with those people and managing to provide sane software here. I applaud their attempt to patch this out for a time. I applied the -N to my aliases, but seriously, what the hell. – remram May 01 '18 at 03:54
  • 2
    My alias for ls includes -l, which lists each file on a separate line. Extra quoting just adds noise. Obviously, this should have been an opt-in. Then, Debian could have enabled it by adding a switch in their default .bashrc. – Roger Dahl Jul 20 '18 at 15:42
  • 3
    Opt-out bad, opt-in good. But apparently the coreutils devs prefer to be added to mailing lists automatically and get the option to opt-out later. Yeah, right. – Jürgen A. Erhard Aug 06 '18 at 12:03
  • 5
    @RogerDahl Even if you're not using -l, the output is already in columns, so it still just adds noise... that's why I'm here now. – Izkata Jul 19 '19 at 02:39
140

You can chose quoting style:

ls --quoting-style=literal

The same as:

ls -N

or:

QUOTING_STYLE=literal ls

Make it an alias, or set export QUOTING_STYLE=literal in your .bashrc to achieve pre-8.25 behavior.

Lekensteyn
  • 20,830
cuonglm
  • 153,898
  • 17
    seems a bit weird I have to do that to get normal unix-y behavior. Also, I want the old default. I don't think escaping was the old default - I think it printed exactly what was actually there. – Wyatt Ward Jan 30 '16 at 15:58
  • @Wyatt8740: Yes, then just chose your own prefer style. – cuonglm Jan 30 '16 at 16:01
  • 14
    For pre-8.25 behavior, use export QUOTING_STYLE=literal in your bashrc. – Lekensteyn Jan 31 '16 at 11:07
  • 3
    or use -N, it seems. I'm just compiling my own version since I already have a personal repository set up. – Wyatt Ward Jan 31 '16 at 15:12
  • 1
    @Lekensteyn, would you post that as an answer? Like, I think, the original poster, that's the quoting style that I want, but I would have missed it if I didn't read the comments. (I appreciate that this is helpfully undocumented under man ls.) – LSpice Feb 15 '16 at 23:13
  • 2
    @LSpice I have edited the post to use literal instead of escape (I believe that @cuonglm just wanted to show how to change the style, not specifically targetting the escape style). – Lekensteyn Feb 16 '16 at 10:31
  • @Lekensteyn (thanks for the edit!) and cuongym, is that ls at the end of the invocation QUOTING_STYLE=literal ls supposed to be there? I can't find any documentation on the QUOTING_STYLE variable, or on the possible options for it, but it seems that omitting ls gives the same effect. – LSpice Feb 16 '16 at 10:44
  • 1
    @LSpice See the bottom of every coreutils manpage, Full documentation at: http://www.gnu.org/software/coreutils/ls or available locally via: info '(coreutils) ls invocation' – Lekensteyn Feb 21 '16 at 10:02
  • @Lekensteyn, thanks! (I sure do lament the trend of man pages just being pointers to info pages ….) It does seem that the ls at the end of the QUOTING_STYLE variable is unnecessary, right? – LSpice Feb 21 '16 at 19:08
  • 1
    @LSpice It is significant. If you would execute QUOTING_STYLE=literal and ls separately, then ls will not pick this up as you are just setting a local shell variable which is not seen by the child process (ls). QUOTING_STYLE=literal ls will execute ls with the QUOTING_STYLE environment variable set for that specific execution. Compare that to export QUOTING_STYLE=literal which will make the variable available to all following child processes. – Lekensteyn Feb 22 '16 at 19:14
  • export QUOTING_STYLE=literal doesn't work for me in Ubuntu 16.04.2 LTS (in Windows Subsystem for Linux), but ls -N works. – Alexia Luna Jun 30 '17 at 10:58
  • @nyuszika7h check your ls version – cuonglm Jun 30 '17 at 16:40
  • @cuonglm It's 8.25, but never mind, turns out I had -b in my ls alias. – Alexia Luna Jun 30 '17 at 16:48
  • 10
    This answer deserves more upvotes. It straightly addresses what the questioner asked avoiding a bureaucratic answer. Indeed, the environment variable approach seems pretty elegant. (I personally prefer the new behavior as it favors a more efficient C&P action), yet, ls is clever enough to behave the old way when a redirection is used, so no harm to scripts that uses ls' output. – Marcelo Nov 24 '17 at 01:17
  • 1
    @marcelo I did upvote it, but it's still somewhat unsatisfying when the default behavior is incorrect. – Wyatt Ward Oct 06 '19 at 20:50
58

A few points about the change.

  • It was introduced in coreutils v8.25, and alignment improved in v8.26
  • It only happens when outputting to terminals so doesn't break scripts
  • It disambiguates the output for users for files containing whitespace
  • It sanitizes output so it is safe to copy and paste
  • Output is now always valid to copy and paste back to shell
  • Users can get back to the old format by adding -N to their ls alias
Pádraig Brady
  • 3,242
  • 8
    my last example isn't ambiguous? Perhaps not - but it's certainly confusing and takes more time to decipher. I think it's an awful change (no offense intended to you). Thanks for the alias tip though. – Wyatt Ward Jan 30 '16 at 15:58
  • 1
    Yes I agree the quoting is not great with single quotes in a file name, however that is not the common case in my experience. Note using "double'quoting" is an option, though that is yet another quoting variant and is less general than single quoting. Personally I try to avoid shell meta chars in file names and if I ever needed an apostrophe in a file name I’d use the preferred unicode one ’ (altgr+0 here). – Pádraig Brady Jan 30 '16 at 16:38
  • I understand that - I think that if people ever use a linux distribution as a desktop, they are likely to download files named by windows users. Single quotes are going to be really confusing then, even if to get the file name it does turn out to just be a 'copy/paste'. Copy/paste isn't very useful in my use case though, and also bash completion listings confuse things further: http://i.imgur.com/Lj3WfCM.jpg The man page doesn't really make it clear that -N removes the "escaping", either, it won't be clear what to do to revert it. I've been using GNU/Linux Maybe that can be clarified? – Wyatt Ward Jan 31 '16 at 00:19
  • (p.s. - thanks for helping. The alias works, though I just made a little patch to ls.c by removing that line. Marking yours as the answer, despite my still feeling like this change should be reverted for 8.26.) – Wyatt Ward Jan 31 '16 at 00:26
  • 3
    p.p.s. - Depending on where you paste to, the escapes don't even help necessarily. Especially pasting into a script or a GUI application. – Wyatt Ward Jan 31 '16 at 00:35
  • lekensteyn: I linked the commit and also already noticed that, thanks for making it clear for others though. and it does break alignment, too. I do not like it at all. – Wyatt Ward Jan 31 '16 at 15:10
  • 4
    I agree w/ @Wyatt8740 - this is not a good idea. At least the default ? substitution is officially acknowledged - this is just off the wall. You are adding characters to filenames which are not in the filenames in the output of a utility which is supposed to list filenames. Doing this to shell-eval-safe said filenames is, as I think, misguided. Unless you do it robustly and shell-quote any possible shell-quotes in your output then you're only trading a bad rare case for a worse one and distorting your output for the sake of it. please do the standard thing whenever possible. – mikeserv Feb 05 '16 at 16:55
  • 13
    my apologies - apparently you are safely shell-quoting the shell-quotes at least. i still do not like it. the options are fine - but altering the very well-specified default behavior of a decades-old unix core utility in such a way that diminishes its veracity can only be a bad idea. – mikeserv Feb 05 '16 at 17:03
  • last, and sorry to pester, but maybe you could just do this in vdirs or something? isn't that what that one is for? – mikeserv Feb 05 '16 at 17:07
  • 3
    Note that copy-pasting still doesn't work in xterm for files like this one created with touch $'Pa\u301draig' where xterm replaces the a\u301 with \ue1. screen or luit can also do some charset conversion which will break copy-pasting. – Stéphane Chazelas Feb 05 '16 at 17:58
  • 3
    @StéphaneChazelas was not aware of that. Yet more reason to make this non-default again. – Wyatt Ward Feb 06 '16 at 03:16
  • 2
    @mikeserv wow, did not even know that vdir was a thing. looks exactly like ls -l. Agreed that this is too blatantly breaking of expected norms to be a good thing. Simplicity should be default, complexity optional if there at all. Do one thing and do it well. – Wyatt Ward Feb 06 '16 at 03:19
  • 2
    @Wyatt8740, @StéphaneChazelas was pointing out that xterm uses normalized composed (NFKC) for output, which is problematic for cut and paste independent of this change in ls. In fact for such cases this ls change can make it possible to reference such files by using LC_ALL=C ls (ps one needs to specify 4 hex chars in the example above, i.e. $'Pa\0301draig') – Pádraig Brady Feb 06 '16 at 19:59
  • 1
    Although I am using the 8.25 GNU ls, my man ls doesn't mention QUOTING_STYLE or the -N switch. Is this a temporary oversight, or is there somewhere else that I should be looking for documentation? – LSpice Feb 15 '16 at 23:14
  • 1
    Well -N is described in the man page (for many releases), though I agree it's a bit confusing and terse. The -N option is better described in the info docs at https://www.gnu.org/software/coreutils/manual/html_node/Formatting-the-file-names.html#Formatting-the-file-names We'll improve the man page ASAP – Pádraig Brady Feb 16 '16 at 00:36
  • 6
    "Users can get back to the old format by adding -N to their ls alias"

    Users could already set QUOTING_STYLE=shell if they wanted this output. Changing the default has only caused more work for distros.

     – bobpaul Mar 06 '16 at 17:51
  • 4
    "Suggesting" to add an argument to revert to the old, default behaviour is indeed a bad idea. –  May 26 '16 at 13:46
  • 1
    coreutils-8.26 now better aligns quoted items, which also better indicates that quoting is not actually part of the name. Also items with single quotes are quoted more concisely using double quotes – Pádraig Brady Dec 07 '16 at 23:03
  • @PádraigBrady Have not tried 8.26 yet, but 8.25 fails to shell-escape UTF-8 japanese from a SHIFT_JIS terminal and locale. Don't know if that's fixable though due to the highly unusual nature of SHIFT_JIS. – Wyatt Ward Dec 08 '16 at 00:25
  • @Wyatt8740 There is no way that one can accurately distinguish non-printable UTF-8 characters, when interpreting as SHIFT_JIS. The best I could suggest it to display the ASCII subset of both and escape the rest, which you can do like LC_ALL=C ls – Pádraig Brady Dec 08 '16 at 19:36
  • @PádraigBrady Kind of expected that to be the case. At some level everything's just a byte after all. – Wyatt Ward Dec 10 '16 at 20:09
  • 2
    "It only happens when outputting to terminals so doesn't break scripts" – That's good, I guess, but nobody should ever parse the output of ls in a script anyway. Unfortunately, it's done way too often. – Alexia Luna Jun 30 '17 at 10:55
  • 7
    @PádraigBrady I'm grateful for the work you do in maintaining coreutils. But changing the default formatting for ls was a mistake. The simple fix is to make the new formatting "opt-in". Distros already contain .bashrc files that typically tweak the behavior of ls and other coreutils, adding colors, etc. That would be the right place to enable the new formatting for the ones that want it. – Roger Dahl Jul 20 '18 at 16:40
  • 1
    I too was taken aback when I first encountered this change. However, I deal with a lot of filenames with spaces so I soon realised this new behaviour makes the output of ls more readable. Previously, if I wanted to clearly list the contents of a directory, I had to provide the -l or -1 option so each filename is output on a separate line (which can quickly fill the terminal). Now, I get a file listing that’s both compact and clear. I wouldn’t otherwise post this comment, but if you were to read the other comments, you’d get the impression that this new default was universally unwanted. – Anthony Geoghegan Jun 17 '19 at 12:01
  • 4
    For what it’s worth, I checked the POSIX specification and it states that “If the output is to a terminal, the format is implementation-defined” so this change is still standards-compliant. – Anthony Geoghegan Jun 17 '19 at 12:02
  • 3
    I'm astonished to see so negativity in the comments to this answer. This change is excellent and much welcomed. It is essentially a security fix, so it's perfectly reasonable and expected to enable it by default. If it broke any of your stuff, your stuff was most likely insecure in the first place. – b0fh Aug 23 '19 at 12:15
  • So when I have a file which really has quotes on its name lets say 'xxx' it appears as "'xxx'", ok wonderful, what I won't be able to read is the REAL NAME OF THE FILE, which I guess is not important for most purposes other than working, really may be a wonderful feature, do not discuss that, but not default behaviour. – tonio Jun 02 '20 at 02:52
  • 2
    count me in as an affected user of this bug deliberately introduced by the current developers of ls. – bliako Sep 14 '21 at 19:22