Debian Bug report logs - #813164
coreutils: ls suddenly quotes output

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Thorsten Glaser <tg@mirbsd.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: coreutils: ls suddenly quotes output

Date: Sat, 30 Jan 2016 01:50:12 +0100

Package: coreutils
Version: 8.25-1
Severity: minor

tglase@tglase-nb:~ $ mkdir -p foo/{a,b\ c}; cd foo; /bin/ls                                                     
a  'b c'

’nuff said… this *should* be:

(pbuild17294)root@tglase-nb:/# mkdir -p foo/{a,b\ c}; cd foo; /bin/ls
a  b c



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages coreutils depends on:
ii  libacl1            2.2.52-2
ii  libattr1           1:2.4.47-2
ii  libc6              2.21-7
ii  libselinux1        2.4-3
ii  multiarch-support  2.21-7

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Message #10 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Pádraig Brady <P@draigBrady.com>

To: Thorsten Glaser <tg@mirbsd.de>, 813164@bugs.debian.org

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Fri, 29 Jan 2016 23:41:15 -0800

On 29/01/16 16:50, Thorsten Glaser wrote:
> Package: coreutils
> Version: 8.25-1
> Severity: minor
> 
> tglase@tglase-nb:~ $ mkdir -p foo/{a,b\ c}; cd foo; /bin/ls                                                     
> a  'b c'
> 
> ’nuff said… this *should* be:
> 
> (pbuild17294)root@tglase-nb:/# mkdir -p foo/{a,b\ c}; cd foo; /bin/ls
> a  b c

A few points about the change.

- It only happens when outputting to terminals
- It disambiguates the output for users
- Output can be pasted back in the shell for further processing
- Users can get back to the old format by adding -N to their ls alias

cheers,
Pádraig

Message #15 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 813164@bugs.debian.org

Subject: Re: coreutils: ls suddenly quotes output

Date: Sun, 31 Jan 2016 00:45:55 +0100

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

Hey.

I've also just stumbled over this... while the idea is nice in
principle, I think it's quite dangerous as well... even if behaviour is
preserved when output goes to a terminal.

a) The quotation alone doesn't necessarily help with copy&paste,
depending on where you paste.

b) When the pasted content is actually further to be processed by e.g.
old scripts (which expect perhaps one *unquoted* name per line) things
will fail.

c) We now have what you see is NOT what you get [when stdout is not a
terminal]
People do use ls in all it's variations in countless of scripts, and
they build up their scripts by first trying it out on the terminal to
see what they get is what they want to have in the script.
But now, what they get is different in both.
And the change isn't necessarily one that get's noticed, but it still
may lead to all kinds of garbage, wrong files being deleted and so on.

Consider a user writes a script that shall deleted all files from
2012... a stupid solution may be something like:
rm -f "$( ls -1l | grep <some pattern that matches the date column> | sed "some pattern that removes everything up the filename" | xargs )"
On the terminal this may give proper:
rm -f 'file with spaces mythesis.pdf'
in the script this would give
rm -f file with spaces mythesis.pdf

Well I'm not claiming that the above way is a proper way to delete
files from 2012 ;-) ... but people often do such things...


Long story short... this shouldn't be default but a opt-in.

And if it really stays default, which seems just like tickling the
dragon, it needs a NEWS.Debian entry.


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #20 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 813164@bugs.debian.org

Subject: Re: Bug#813164: Info received (coreutils: ls suddenly quotes output)

Date: Sun, 31 Jan 2016 01:09:08 +0100

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

On Sat, 2016-01-30 at 23:51 +0000, Debian Bug Tracking System wrote:
> Thank you for the additional information you have supplied regarding
> this Bug report.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due
> course.
> 
> Your message has been sent to the package maintainer(s):
>  Michael Stone <mstone@debian.org>
> 
> If you wish to submit further information on this problem, please
> send it to 813164@bugs.debian.org.
> 
> Please do not send mail to owner@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #25 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 813164@bugs.debian.org

Subject: Re: Bug#813164: Info received (coreutils: ls suddenly quotes output)

Date: Sun, 31 Jan 2016 01:09:56 +0100

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

sorry for the last one... I meant to reply to the subscription
challenge mail,... but got the wrong one :(

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #30 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Pádraig Brady <P@draigBrady.com>

To: Christoph Anton Mitterer <calestyo@scientia.net>, 813164@bugs.debian.org

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Sat, 30 Jan 2016 19:03:27 -0800

On 30/01/16 15:45, Christoph Anton Mitterer wrote:
> Hey.
> 
> I've also just stumbled over this... while the idea is nice in
> principle, I think it's quite dangerous as well... even if behaviour is
> preserved when output goes to a terminal.
> 
> a) The quotation alone doesn't necessarily help with copy&paste,
> depending on where you paste.
> 
> b) When the pasted content is actually further to be processed by e.g.
> old scripts (which expect perhaps one *unquoted* name per line) things
> will fail.
> 
> c) We now have what you see is NOT what you get [when stdout is not a
> terminal]
> People do use ls in all it's variations in countless of scripts, and
> they build up their scripts by first trying it out on the terminal to
> see what they get is what they want to have in the script.
> But now, what they get is different in both.
> And the change isn't necessarily one that get's noticed, but it still
> may lead to all kinds of garbage, wrong files being deleted and so on.
> 
> Consider a user writes a script that shall deleted all files from
> 2012... a stupid solution may be something like:
> rm -f "$( ls -1l | grep <some pattern that matches the date column> | sed "some pattern that removes everything up the filename" | xargs )"
> On the terminal this may give proper:
> rm -f 'file with spaces mythesis.pdf'
> in the script this would give
> rm -f file with spaces mythesis.pdf

ls output really isn't amenable to further processing.
That's what find(1) is focused on.
Though I see what you're saying.

Let's try and force your example into something concrete.
You're saying that people might assume files are always quoted,
but I'm explicitly adding the --quoting option below to
see if users did notice to do that, whether further
processing of ls is valid anyway.

# Very carefully format ls output for processing
ls -ln --quoting=shell-escape --block-size=1 --time-style='+%m' |
# Get rid of the first few space aligned fields while not
# impacting consecutive spaces in a file name.
sed 's/\([^ ]* \)\{4\}//; s/^ *[^ ]* //' |
# Pick files in January
grep ^01 |
# Get the quoted file names
cut -d' ' -f2-
# Process them
xargs ...


Now this mostly works, right up until xargs,
but that will only strip single quotes.
It will not process $'\n' quoting that ls may also output.

Also given the extreme awkwardness in the filtering above,
users are really going to be and should be using find(1) instead.

So yes you have a valid point,
but it's quite a contrived situation.

cheers,
Pádraig.

Message #35 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: Pádraig Brady <P@draigBrady.com>, 813164@bugs.debian.org

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Sun, 31 Jan 2016 05:28:20 +0100

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

On Sat, 2016-01-30 at 19:03 -0800, Pádraig Brady wrote:
> ls output really isn't amenable to further processing.
> That's what find(1) is focused on.
Sure... as I've said... it's neither the best example, nor the best way
to solve the problem from that example.

But you can also consider things like: "get a list of files in a
directory, assuming no strange filenames (i.e. such with ' or newlines
are used).
Simple solution:
ls -1

Wanna further process these files?
ls -1 | sed "s/^/'/; s/$/'/"

Process them further
listOfFiles="$(ls -1 | sed "s/^/'/; s/$/'/" | xargs)"
or something like that

Still perhaps not the best way to handle things (fails at least with
newlines and ' in file names), but probably more likely to be found in
the wild.

It's some time ago since I last tried that, but IIRC, there were
several cases of invoking bash and some more corner cases when this is
done via ssh.
The most obvious one would be something like:
ssh -t host "ls"
but this is not even what that what I vaguely remember.

So one would probably need to check, whether the assumption, that the
check for whether a terminal is connected or not is actually enough for
all cases.
Perhaps not.


> Let's try and force your example into something concrete.
> You're saying that people might assume files are always quoted,
that's another case where it may cause trouble...

> but I'm explicitly adding the --quoting option below to
> see if users did notice to do that, whether further
> processing of ls is valid anyway.
mhh... question is just whether people actually notice that option and
use it.


> So yes you have a valid point,
> but it's quite a contrived situation.
Well it's difficult what to do... but changing the output format of
such base tools like ls per default seems to call for problems.


Best wishes,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #40 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: Pádraig Brady <P@draigBrady.com>, 813164@bugs.debian.org

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Sun, 31 Jan 2016 07:08:24 +0100

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

One further reason that may speak against this:

Just by looking at some ls output it's now ambiguous, whether
'foo bar'
is the quoted version of a file named “foo bar” or whether it's an
unquoted version of a file named “'foo bar'”.

As I've said, by just by looking at some output (or e.g. copy and
pasted stuff). I *do* notice that ls (with quoting) will actually quote
a file “'foo bar'” to: “''\''foo bar'\'''”... which is btw a bit
strange form of quoting AFAIU, “\''foo bar'\'” would have been enough.

Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #45 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Thorsten Glaser <tg@mirbsd.de>

To: Pádraig Brady <P@draigBrady.com>

Cc: 813164@bugs.debian.org

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Mon, 1 Feb 2016 14:52:40 +0000 (UTC)

Pádraig Brady dixit:

>A few points about the change.

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

But you didn’t make the -F option default either.

It’s common that new functionality is enabled by a switch,
not by default, so you should have made -N enable this and
keep it disabled by default to prevent very irritated reactions
from users.

bye,
//mirabilos
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

Message #50 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 813164@bugs.debian.org

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Mon, 01 Feb 2016 18:11:48 +0100

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

On Mon, 2016-02-01 at 14:52 +0000, Thorsten Glaser wrote:
> It’s common that new functionality is enabled by a switch,
> not by default, so you should have made -N enable this and
> keep it disabled by default to prevent very irritated reactions
> from users.
It should perhaps further be noted, that -N, at least according to how
I understand the manpage, doesn't really just revert the quoting... it
also says "don't treat e.g. control characters  specially" and IIRC
this *was* already done before, or wasn't it?

Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #55 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Jamie Heilman <jamie@audible.transient.net>

To: 813164@bugs.debian.org

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Tue, 2 Feb 2016 21:19:38 +0000

This behavior needs to be reverted.  There are too many assumptions
being made, the quoting used is shell-specific, and not universally
supported.  For example, consider a file who's name contains a tab,
like "a<tab>b".

$ ls
'a'$'\t''b'

OK, so that syntax is supported by bash and zsh, so if you're using
one of those shells, maybe you know what it means, and you can cut and
paste that and make use of it, but in csh or dash, it doesn't mean the
same thing.

Message #60 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Pádraig Brady <P@draigBrady.com>

To: Jamie Heilman <jamie@audible.transient.net>, 813164@bugs.debian.org

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Tue, 2 Feb 2016 18:54:35 -0800

On 02/02/16 13:19, Jamie Heilman wrote:
> This behavior needs to be reverted.  There are too many assumptions
> being made, the quoting used is shell-specific, and not universally
> supported.  For example, consider a file who's name contains a tab,
> like "a<tab>b".
> 
> $ ls
> 'a'$'\t''b'
> 
> OK, so that syntax is supported by bash and zsh, so if you're using
> one of those shells, maybe you know what it means, and you can cut and
> paste that and make use of it, but in csh or dash, it doesn't mean the
> same thing.

$'...' is in the process of being POSIX standardized.

Even when the shell doesn't support it directly yet,
surely \t is better than ?

Message #65 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Jamie Heilman <jamie@audible.transient.net>

To: Pádraig Brady <P@draigBrady.com>

Cc: 813164@bugs.debian.org

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Wed, 3 Feb 2016 04:54:03 +0000

Pádraig Brady wrote:
> On 02/02/16 13:19, Jamie Heilman wrote:
> > This behavior needs to be reverted.  There are too many assumptions
> > being made, the quoting used is shell-specific, and not universally
> > supported.  For example, consider a file who's name contains a tab,
> > like "a<tab>b".
> > 
> > $ ls
> > 'a'$'\t''b'
> > 
> > OK, so that syntax is supported by bash and zsh, so if you're using
> > one of those shells, maybe you know what it means, and you can cut and
> > paste that and make use of it, but in csh or dash, it doesn't mean the
> > same thing.
> 
> $'...' is in the process of being POSIX standardized.
>
> Even when the shell doesn't support it directly yet,
> surely \t is better than ?

No, it isn't.  Nothing about this behavior is desirable at all.
Unless your goal is to make everyone stop using GNU core utilities
entirely, it will probably see some success at that.

Message #68 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Christoph Berg <myon@debian.org>

To: Jamie Heilman <jamie@audible.transient.net>, 813164@bugs.debian.org

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Wed, 3 Feb 2016 11:42:54 +0100

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

Re: Jamie Heilman 2016-02-02 <20160202211938.GB4090@cucamonga.audible.transient.net>
> This behavior needs to be reverted.  There are too many assumptions
> being made, the quoting used is shell-specific, and not universally
> supported.  For example, consider a file who's name contains a tab,
> like "a<tab>b".
> 
> $ ls
> 'a'$'\t''b'

Urgh. Similarly unreadable:

$ touch "o'really"
$ ls o*y
'o'\''really'

> OK, so that syntax is supported by bash and zsh, so if you're using
> one of those shells, maybe you know what it means, and you can cut and
> paste that and make use of it, but in csh or dash, it doesn't mean the
> same thing.

First of all I want to *read* the ls output. I'm not interested in
funky shell characters there.

Please revert this feature.

Christoph
-- 
cb@df7cb.de | http://www.df7cb.de/

[signature.asc (application/pgp-signature, inline)]

Message #73 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Adam Borowski <kilobyte@angband.pl>

To: 813164@bugs.debian.org

Subject: what's the point of the change?

Date: Wed, 3 Feb 2016 14:47:11 +0100

As the new behavious applies only to tty display, the only reason could be
making the output more palatable to the user.  Except, it is not -- the
change might be somewhat excused when such a file name is a rare exception,
but it makes things really hard to read when you have a mix of one-word and
multi-word names.

Even worse case is when you have an apostrophe in a file name.  That's a
frequent case whenever file names are titles.

Message #78 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Adam Borowski <kilobyte@angband.pl>

To: 813164@bugs.debian.org

Subject: revert of upstream commit

Date: Wed, 3 Feb 2016 15:00:30 +0100

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

Control: tags -1 +patch

The offending commit is 109b9220cead6e979d22d16327c4d9f8350431cc upstream.
Here's a patch that reverts it, with conflicts resolved.  This includes
documentation changes, if you don't want those, it's an one-liner.

-- 
A tit a day keeps the vet away.

[no_ls_quoting.patch (text/x-diff, attachment)]

Message #85 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Adam Borowski <kilobyte@angband.pl>

To: 813164@bugs.debian.org

Subject: alias ls='ls -N' is not a solution

Date: Wed, 3 Feb 2016 15:05:14 +0100

Also, the proposed workaround, "alias ls='ls -N'" doesn't act reasonably.
It disables _all_ quoting, including nasty unprintable characters.  When the
output goes to the terminal, it is meant to be read by a human.  Humans can
read spaces and apostrophes just fine, they can't read \1 or broken UTF-8.

-- 
A tit a day keeps the vet away.

Message #90 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org>

To: 813164@bugs.debian.org

Subject: Re: coreutils: ls suddenly quotes output

Date: Wed, 03 Feb 2016 15:08:19 +0100

Hi,

as this came up in #-devel, I must admit that I actually prefer the new
behaviour slightly: before "ls" used to apply a non-injective mapping
to filenames.  The new transformation is at least injective, an
advantage when dealing with strange filenames in strange encodings.

For sane filenames (only ASCII alphanumerics and a few extra
characters, but no whitespace or quotes) nothing changes anyway ;)

Note that "ls" and "ls | cat" (output to tty vs no-tty) already
differed before.

Arguably a different output (C escape) codes might be more readable for
users: compare

  'new'$'\n''line'

vs

  new\nline

where the user has to add the $'...' himself when using the filename in
a shell.

Ansgar

Message #95 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: 813164@bugs.debian.org

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Wed, 3 Feb 2016 09:05:14 -0500

Does anyone want to chime in with support for the change? I'm mostly 
ambivalent, but then I don't have a lot of filenames that are actually 
affected.

Mike Stone

Message #100 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: 813164@bugs.debian.org, Pádraig Brady <P@draigBrady.com>

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Wed, 03 Feb 2016 15:18:15 +0100

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

On Wed, 2016-02-03 at 04:54 +0000, Jamie Heilman wrote:
> Nothing about this behavior is desirable at all.
I don't think this is true either... the feature definitely has it's
point... even though I rather think it's to invasive to have it per
default.

I think especially the "what you see [is no longer] what you get" point
makes this feature problematic to be enabled per default (a problem
which doesn't exist e.g. in the case of just colourisations).




On Wed, 2016-02-03 at 11:42 +0100, Christoph Berg wrote:
> Urgh. Similarly unreadable:
> 
> $ touch "o'really"
> $ ls o*y
> 'o'\''really'

Though that could be fixed... a smart quoting algorithm could produce
something like.
o\'really
or
"o'really"




On Wed, 2016-02-03 at 15:08 +0100, Ansgar Burchardt wrote:
> Note that "ls" and "ls | cat" (output to tty vs no-tty) already
> differed before.
But IIRC only in terms of the former using columns?



Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #105 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Christoph Anton Mitterer <calestyo@scientia.net>, 813164@bugs.debian.org

Cc: Pádraig Brady <P@draigBrady.com>

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Wed, 3 Feb 2016 09:24:02 -0500

On Wed, Feb 03, 2016 at 03:18:15PM +0100, Christoph Anton Mitterer wrote:
>Though that could be fixed... a smart quoting algorithm could produce
>something like.
>o\'really
>or
>"o'really"

That acutally exists: see --quoting-style=c 
also check out --quoting-style=escape

Mike Stone

Message #110 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Adam Borowski <kilobyte@angband.pl>

To: 813164@bugs.debian.org

Subject: some limited support -- and not

Date: Wed, 3 Feb 2016 15:34:21 +0100

> Does anyone want to chime in with support for the change?

There are cases when it does make sense: unprintable characters.

15:25 < ansgar> Now, 'new'$'\t''line' could also be $'new\tline' or
                new\tline.  But any of these is better than new?line

with which I do agree.  Thus, the handling of unprintables could use some
improvement (although '$'\t'' is too long).


I don't think mangling filenames with spaces is acceptable, though.

> I'm mostly ambivalent, but then I don't have a lot of filenames that are
> actually affected.

find ~ -name '* *'|wc -l
9194

-- 
A tit a day keeps the vet away.

Message #115 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org>

To: 813164@bugs.debian.org

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Wed, 03 Feb 2016 15:48:36 +0100

On Wed, 03 Feb 2016 15:18:15 +0100 Christoph Anton Mitterer wrote:
> I think especially the "what you see [is no longer] what you get"
> point makes this feature problematic to be enabled per default (a
> problem which doesn't exist e.g. in the case of just colourisations).

That is already the case, see below.

> On Wed, 2016-02-03 at 11:42 +0100, Christoph Berg wrote:
> > Urgh. Similarly unreadable:
> > 
> > $ touch "o'really"
> > $ ls o*y
> > 'o'\''really'
> 
> Though that could be fixed... a smart quoting algorithm could produce
> something like.
> o\'really
> or
> "o'really"

Yes, I personally find "ls -b" more readable than the new default. It's
still easy to paste in a shell: just $'<paste-here>'  (well, almost: -b
would have to escape "'" too)

Note that "ls -b" still escapes a space:

  $ ls -db Vir*
  VirtualBox\ VMs

Not escaping " " (space) would be okay for me, though it makes multi-
column output ambigious when dealing with bad names: is "a  b" two
files "a" and "b", or one file "a  b"?  Solutions like not escaping a
single space, but escaping either all or only all except the first
space feel more confusing then always escaping spaces in tty output.

> On Wed, 2016-02-03 at 15:08 +0100, Ansgar Burchardt wrote:
> > Note that "ls" and "ls | cat" (output to tty vs no-tty) already
> > differed before.
> But IIRC only in terms of the former using columns?

No, they are totally different: one of them can output "??????????" for
a file whose name doesn't contain a single question mark.  And generate
the same output for a different filename too (yay!).  Such filenames
one can for example encounter by extracting archives using legacy Asian
encodings.

I already enjoyed this in the past and if a mapping is applied to not
output control characters as-is to a terminal (a reasonable choice),
that mapping should in my opinion at least be injective.

Ansgar

Message #120 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Adam Borowski <kilobyte@angband.pl>, 813164@bugs.debian.org

Subject: Re: Bug#813164: some limited support -- and not

Date: Wed, 3 Feb 2016 10:05:59 -0500

On Wed, Feb 03, 2016 at 03:34:21PM +0100, you wrote:
>> Does anyone want to chime in with support for the change?
>
>There are cases when it does make sense: unprintable characters.
>
>15:25 < ansgar> Now, 'new'$'\t''line' could also be $'new\tline' or
>                new\tline.  But any of these is better than new?line
>
>with which I do agree.  Thus, the handling of unprintables could use some
>improvement (although '$'\t'' is too long).

I'm actually not convinced this is true. Does it actually matter in 
general what the specific character is that accidentally got inserted 
into a filename? Like, when does it matter whether it's randomgarbage\t 
or randomgarbage\n or randomgarbage\a or whatever? Do people often do 
anything other than rm randomgarbage<tab> ? 

Mike Stone

Message #125 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Adam Borowski <kilobyte@angband.pl>

To: 813164@bugs.debian.org

Subject: Re: Bug#813164: some limited support -- and not

Date: Wed, 3 Feb 2016 16:20:44 +0100

On Wed, Feb 03, 2016 at 10:05:59AM -0500, Michael Stone wrote:
> On Wed, Feb 03, 2016 at 03:34:21PM +0100, you wrote:
> >There are cases when it does make sense: unprintable characters.
> >
> >15:25 < ansgar> Now, 'new'$'\t''line' could also be $'new\tline' or
> >               new\tline.  But any of these is better than new?line
> >
> >with which I do agree.  Thus, the handling of unprintables could use some
> >improvement (although '$'\t'' is too long).
> 
> I'm actually not convinced this is true. Does it actually matter in general
> what the specific character is that accidentally got inserted into a
> filename? Like, when does it matter whether it's randomgarbage\t or
> randomgarbage\n or randomgarbage\a or whatever? Do people often do anything
> other than rm randomgarbage<tab> ?

You have a point.  I guess, the big question here is: what's the main
purpose of ls's output?  Is it showing the directory's contents in
human-friendly way?  Or is it something that needs to be a reversible
transformation?

I for one prefer the former, Ansgar seems to want the latter.

Also, should we consider junk in file names to be an error or a valid use
case?

This reminds me: it's high time to write a kernel patch to ban creation of
files which fail iswprint(), like some filesystems already do for broken
Unicode.

-- 
A tit a day keeps the vet away.

Message #130 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: 813164@bugs.debian.org

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Wed, 3 Feb 2016 16:30:17 +0100

Hi,

Jamie Heilman wrote:
> This behavior needs to be reverted.

Definitely. Please apply kilobyte's patch, either upstream
(preferably) or at least in Debian.

> For example, consider a file who's name contains a tab, like
> "a<tab>b".

I just stumbled over a case where the quoting is even unnecessary:

→ touch foo@bar.txt
→ ls 
'foo@bar.txt'

This smells rather perl-ish than shell-ish.

Again: Please revert this unlucky change which is IMHO based on rather
naïve (and wrong) assumptions ("It should not have backwards compat
issues").

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Message #135 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: 813164@bugs.debian.org

Subject: Re: Bug#813164: some limited support -- and not

Date: Wed, 3 Feb 2016 16:34:12 +0100

Hi,

Adam Borowski wrote:
> Also, should we consider junk in file names to be an error or a valid use
> case?

Valid use case of course. Anything that doesn't contain a null byte or
a slash is a valid file name.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Message #140 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org>

To: 813164@bugs.debian.org

Subject: Re: Bug#813164: some limited support -- and not

Date: Wed, 03 Feb 2016 16:46:57 +0100

On Wed, 2016-02-03 at 16:20 +0100, Adam Borowski wrote:
> On Wed, Feb 03, 2016 at 10:05:59AM -0500, Michael Stone wrote:
> > On Wed, Feb 03, 2016 at 03:34:21PM +0100, you wrote:
> > > There are cases when it does make sense: unprintable characters.
> > > 
> > > 15:25 < ansgar> Now, 'new'$'\t''line' could also be $'new\tline'
> > > or
> > >               new\tline.  But any of these is better than
> > > new?line
> > > 
> > > with which I do agree.  Thus, the handling of unprintables could
> > > use some
> > > improvement (although '$'\t'' is too long).
> > 
> > I'm actually not convinced this is true. Does it actually matter in
> > general
> > what the specific character is that accidentally got inserted into
> > a
> > filename? Like, when does it matter whether it's randomgarbage\t or
> > randomgarbage\n or randomgarbage\a or whatever? Do people often do
> > anything
> > other than rm randomgarbage<tab> ?

The "\n" was just because I was too lazy to construct a better example.

> You have a point.  I guess, the big question here is: what's the main
> purpose of ls's output?  Is it showing the directory's contents in
> human-friendly way?  Or is it something that needs to be a reversible
> transformation?
> 
> I for one prefer the former, Ansgar seems to want the latter.

A human-friendly reversible transformation ;)

> Also, should we consider junk in file names to be an error or a valid
> use case?
> 
> This reminds me: it's high time to write a kernel patch to ban
> creation of files which fail iswprint(), like some filesystems
> already do for broken
> Unicode.

I'm fairly sure POSIX requires that almost all garbage can be part of
filenames[1].  Also, userland still doesn't default to UTF-8 when no
LC_* variable is set.  This is what "ls" does then:

$ LC_ALL=C ls ~/Music
??????????????????????????????????????????????????????
?????????????????? ??????????????????????????????vs???????????????
???????????? Original Sound Track
...

(Which is pretty much the same as "ls" on non-UTF-8 filenames in an
UTF-8 locale I mentioned in an earlier mail.)

That's pretty useless. Any escaped form is more helpful.

Ansgar

  [1] At least a "filename" is defined as a byte string consisting of 
      anything except \0 and /:
      http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap0
3.html#tag_03_170

      There's also a "portable filename character set", but that is
      only [A-Za-z0-9_.-] and mentioned in the definition of
      "pathname": if only characters from the portable set are used
      in the filename, the name is usable in all locales as a character
      string, otherwise it's just a string.

      I'm not quite sure what *must* be supported to be usable though;
      I remember reading that "everything" as allowed, but couldn't
      find a reference right now.

Message #145 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Ansgar Burchardt <ansgar@debian.org>, 813164@bugs.debian.org

Subject: Re: Bug#813164: some limited support -- and not

Date: Wed, 3 Feb 2016 10:56:11 -0500

On Wed, Feb 03, 2016 at 04:46:57PM +0100, you wrote:
>I'm fairly sure POSIX requires that almost all garbage can be part of
>filenames[1].  Also, userland still doesn't default to UTF-8 when no
>LC_* variable is set.  This is what "ls" does then:
>
>$ LC_ALL=C ls ~/Music
>??????????????????????????????????????????????????????
>?????????????????? ??????????????????????????????vs???????????????
>???????????? Original Sound Track
>...
>
>(Which is pretty much the same as "ls" on non-UTF-8 filenames in an
>UTF-8 locale I mentioned in an earlier mail.)
>
>That's pretty useless. Any escaped form is more helpful.

How? What is the escaped form?

Mike Stone

Message #150 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org>

To: 813164@bugs.debian.org

Subject: Re: Bug#813164: some limited support -- and not

Date: Wed, 03 Feb 2016 17:14:09 +0100

On Wed, 2016-02-03 at 10:56 -0500, Michael Stone wrote:
> On Wed, Feb 03, 2016 at 04:46:57PM +0100, you wrote:
> > I'm fairly sure POSIX requires that almost all garbage can be part
> > of
> > filenames[1].  Also, userland still doesn't default to UTF-8 when
> > no
> > LC_* variable is set.  This is what "ls" does then:
> > 
> > $ LC_ALL=C ls ~/Music
> > ??????????????????????????????????????????????????????
> > ?????????????????? ??????????????????????????????vs???????????????
> > ???????????? Original Sound Track
> > ...
> > 
> > (Which is pretty much the same as "ls" on non-UTF-8 filenames in an
> > UTF-8 locale I mentioned in an earlier mail.)
> > 
> > That's pretty useless. Any escaped form is more helpful.
> 
> How? What is the escaped form?

It's not much more helpful as it is still not human-readable (for "ls
-b" it's something like lots of \123\456..., with the new default
something like $'\123\456...'), but it is "good enough" to be able to
at least access the files in some way.  Sequences of question marks of
the same length don't even allow that minimal usability: if you have
two files both shown as "????????", there is no easy way to inspect and
rename *one* of them.

If they are shown as \123\456, then I can at least copy & paste that
name and use it.  Which is why I think the idea of the changes
implemented in the new coreutils is good in principle (though the
current default quoting variant is IMHO one of the less readable ones).

Ansgar

Message #155 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Ansgar Burchardt <ansgar@debian.org>, 813164@bugs.debian.org

Subject: Re: Bug#813164: some limited support -- and not

Date: Wed, 3 Feb 2016 11:37:25 -0500

On Wed, Feb 03, 2016 at 05:14:09PM +0100, you wrote:
>If they are shown as \123\456, then I can at least copy & paste that
>name and use it.  Which is why I think the idea of the changes
>implemented in the new coreutils is good in principle (though the
>current default quoting variant is IMHO one of the less readable ones).

But that will never work in general because different shells use 
different quoting styles. A more readable version would be something 
like the -Q output ("\123\456") but you can't use that to do the copy 
and paste. This is, I think, a case where most people would just resort 
to a GUI and people with mad command line skills could already cope.

Mike Stone

Message #160 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Adam Borowski <kilobyte@angband.pl>

To: 813164@bugs.debian.org

Subject: Re: Bug#813164: some limited support -- and not

Date: Wed, 3 Feb 2016 17:38:33 +0100

On Wed, Feb 03, 2016 at 04:46:57PM +0100, Ansgar Burchardt wrote:
> I'm fairly sure POSIX requires that almost all garbage can be part of
> filenames[1].  Also, userland still doesn't default to UTF-8 when no
> LC_* variable is set.  This is what "ls" does then:
> 
> $ LC_ALL=C ls ~/Music
> ??????????????????????????????????????????????????????
> ?????????????????? ??????????????????????????????vs???????????????
> ???????????? Original Sound Track
> ...

Which is the closest you can get to the desired output without a
transliteration table (such as
https://github.com/kilobyte/kbtin/blob/master/translit.h) [1].
The C locale simply has no means to display such characters.

> (Which is pretty much the same as "ls" on non-UTF-8 filenames in an
> UTF-8 locale I mentioned in an earlier mail.)

Such characters are an encoding error, and thus ls can reasonably consider
them to be garbage.

>       At least a "filename" is defined as a byte string consisting of 
>       anything except \0 and /:
>       http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap0
> 3.html#tag_03_170
> 
>       There's also a "portable filename character set", but that is
>       only [A-Za-z0-9_.-] and mentioned in the definition of
>       "pathname": if only characters from the portable set are used
>       in the filename, the name is usable in all locales as a character
>       string, otherwise it's just a string.

Which means that implementations must accept at least the portable set, and
are free to decide whether to accept anything else, with the exception of
\0 and /.



[1]. Assuming you can guess the actual encoding, which you have no real way
to.
-- 
A tit a day keeps the vet away.

Message #165 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Pádraig Brady <P@draigBrady.com>

To: Adam Borowski <kilobyte@angband.pl>, 813164@bugs.debian.org

Subject: Re: Bug#813164: alias ls='ls -N' is not a solution

Date: Wed, 3 Feb 2016 17:41:14 -0800

On 03/02/16 06:05, Adam Borowski wrote:
> Also, the proposed workaround, "alias ls='ls -N'" doesn't act reasonably.
> It disables _all_ quoting, including nasty unprintable characters.  When the
> output goes to the terminal, it is meant to be read by a human.  Humans can
> read spaces and apostrophes just fine, they can't read \1 or broken UTF-8.

`ls -N` does revert to the previous behaviour.
I.E. weird chars are replaced with ?

Message #172 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Wouter Verhelst <w@uter.be>

To: Pádraig Brady <P@draigBrady.com>

Cc: Adam Borowski <kilobyte@angband.pl>, 813164@bugs.debian.org

Subject: Re: Bug#813164: alias ls='ls -N' is not a solution

Date: Mon, 8 Feb 2016 01:18:06 +0100

On Wed, Feb 03, 2016 at 05:41:14PM -0800, Pádraig Brady wrote:
> On 03/02/16 06:05, Adam Borowski wrote:
> > Also, the proposed workaround, "alias ls='ls -N'" doesn't act reasonably.
> > It disables _all_ quoting, including nasty unprintable characters.  When the
> > output goes to the terminal, it is meant to be read by a human.  Humans can
> > read spaces and apostrophes just fine, they can't read \1 or broken UTF-8.
> 
> `ls -N` does revert to the previous behaviour.
> I.E. weird chars are replaced with ?

In that case, the documentation is wrong. From the man page:

       -N, --literal
              print raw entry names (don't treat e.g. control characters specially)

That's not what this does. Printing a control character as '?' *is*
treating it specially. Currently, -N behaves as I would expect -q to
behave. Apparently there's no way to ask ls to not process filenames *at
all*. That's just wrong.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Message #177 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Jaroslav Skarvada <jskarvad@redhat.com>

To: 813164@bugs.debian.org

Subject: Re: coreutils: ls suddenly quotes output

Date: Fri, 12 Feb 2016 04:47:18 -0500 (EST)

Hi,

please revert this ugly change, it's confusing and against GNU coding standards [1]:

> Likewise, please don’t make the behavior of a command-line program depend
> on the type of output device it gets as standard output or standard input.
> Device independence is an important principle of the system’s design;
> do not compromise it merely to save someone from typing an option now and then.
> (Variation in error message syntax when using a terminal is ok,
> because that is a side issue that people do not depend on.) 

and:

> Compatibility requires certain programs to depend on the type of output device.
> It would be disastrous if ls or sh did not do so in the way all users expect.

I think most of the users including me do not expect 'ls' to behave such strange
way

thanks & regards

Jaroslav

[1] http://www.gnu.org/prep/standards/standards.html#User-Interfaces

Message #182 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Pádraig Brady <P@draigBrady.com>

To: Jaroslav Skarvada <jskarvad@redhat.com>, 813164@bugs.debian.org

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Fri, 12 Feb 2016 08:20:59 -0800

On 12/02/16 01:47, Jaroslav Skarvada wrote:
> Hi,
> 
> please revert this ugly change, it's confusing and against GNU coding standards [1]:
> 
>> Likewise, please don’t make the behavior of a command-line program depend
>> on the type of output device it gets as standard output or standard input

ls already changed output depending on if output is a tty
We really don't want to adhere to that guideline for ls.

Message #187 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Jaroslav Skarvada <jskarvad@redhat.com>

To: Pádraig Brady <P@draigBrady.com>

Cc: 813164@bugs.debian.org

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Fri, 12 Feb 2016 11:47:05 -0500 (EST)

----- Original Message -----
> On 12/02/16 01:47, Jaroslav Skarvada wrote:
> > Hi,
> > 
> > please revert this ugly change, it's confusing and against GNU coding
> > standards [1]:
> > 
> >> Likewise, please don’t make the behavior of a command-line program depend
> >> on the type of output device it gets as standard output or standard input
> 
> ls already changed output depending on if output is a tty
> We really don't want to adhere to that guideline for ls.
> 

I know that's why there is 'dir' command, but please do not make the situation
worse by diverging the outputs even more in a such confusing way (in default
configuration).

Message #192 received at 813164@bugs.debian.org (full text, mbox, reply):

From: "Jason A. Donenfeld" <Jason@zx2c4.com>

To: 813164@bugs.debian.org

Subject: Re: Bug#813164: coreutils: ls suddenly quotes output

Date: Mon, 15 Feb 2016 20:25:57 +0100

Debian and all sane distros should revert this commit at once.
Changing the aesthetic of ls output is ugly, confusing, and completely
absurd. The developer who made the commit should think twice next time
before introducing such an unwanted setting and making it the default.
This is a change appreciate by nobody, or at least a much smaller
group than those who absolutely detest it.

Message #197 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Wouter Verhelst <w@uter.be>

To: 813164@bugs.debian.org

Subject: This is, in fact, dangerous

Date: Tue, 16 Feb 2016 09:45:46 +0100

A change like this invites security bugs:

J. Random Inexperienced Hacker writes a shell script.

He doesn't know that there is such a thing as the isatty() system call,
and therefore doesn't realize that it is even *possible* to change the
output of a command based on whether standard output refers to a
terminal (I know this described me for about two or three years after I
first started using Unix-like systems).

With the ls version before this change, J. Random Inexperienced Hacker
would see that there are multiple file names on a single line in the
output of ls, decide that ls output is too difficult to parse, and move
on to something else (probably find or some such).

With the ls version after this change, J. Random Inexperienced Hacker
might decide that the quoted nature of the ls output is *ideal* for
parsing, add something along the lines of
INPUT=$(ls /path/to/input/directory)
to his script, and think he's safe against filenames with spaces in them
("because ls quotes output").

The default enabling of the -C option when ls is connected to a terminal
doesn't do harm (and in fact discourages this kind of unsafe behaviour).
However, showing characters that aren't part of a filename in ls output
*by default* is confusing and (as the above shows) potentially
dangerous.

Please revert this change.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Message #200 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org>

To: Wouter Verhelst <w@uter.be>

Cc: 813164@bugs.debian.org

Subject: Re: Bug#813164: This is, in fact, dangerous

Date: Tue, 16 Feb 2016 10:32:48 +0100

Wouter Verhelst <w@uter.be> writes:
> With the ls version before this change, J. Random Inexperienced Hacker
> would see that there are multiple file names on a single line in the
> output of ls, decide that ls output is too difficult to parse, and move
> on to something else (probably find or some such).
>
> With the ls version after this change, J. Random Inexperienced Hacker
> might decide that the quoted nature of the ls output is *ideal* for
> parsing, add something along the lines of
> INPUT=$(ls /path/to/input/directory)
> to his script, and think he's safe against filenames with spaces in them
> ("because ls quotes output").

J Random Inexperienced Hacker already does this in the present day
though.

> The default enabling of the -C option when ls is connected to a terminal
> doesn't do harm (and in fact discourages this kind of unsafe behaviour).
> However, showing characters that aren't part of a filename in ls output
> *by default* is confusing and (as the above shows) potentially
> dangerous.

ls already showed characters that aren't part of a filename *before*
this change:

  $ ls /tmp/a
  a????????????  a????????????

Neither filename contains a question mark, and the filenames are
actually not identical.

One could argue that "ls" should give an error when it encounters any
character that might need quoting instead of enabling quoting by
default. (And this is probably also true when output does not go to a
terminal: at least printing \n as part of a filename is pretty much
always broken.)

Ansgar

Message #205 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Wouter Verhelst <w@uter.be>

To: Ansgar Burchardt <ansgar@debian.org>

Cc: 813164@bugs.debian.org

Subject: Re: Bug#813164: This is, in fact, dangerous

Date: Tue, 16 Feb 2016 10:39:47 +0100

On Tue, Feb 16, 2016 at 10:32:48AM +0100, Ansgar Burchardt wrote:
> Wouter Verhelst <w@uter.be> writes:
> > With the ls version before this change, J. Random Inexperienced Hacker
> > would see that there are multiple file names on a single line in the
> > output of ls, decide that ls output is too difficult to parse, and move
> > on to something else (probably find or some such).
> >
> > With the ls version after this change, J. Random Inexperienced Hacker
> > might decide that the quoted nature of the ls output is *ideal* for
> > parsing, add something along the lines of
> > INPUT=$(ls /path/to/input/directory)
> > to his script, and think he's safe against filenames with spaces in them
> > ("because ls quotes output").
> 
> J Random Inexperienced Hacker already does this in the present day
> though.

Well, yes, possibly.

> > The default enabling of the -C option when ls is connected to a terminal
> > doesn't do harm (and in fact discourages this kind of unsafe behaviour).
> > However, showing characters that aren't part of a filename in ls output
> > *by default* is confusing and (as the above shows) potentially
> > dangerous.
> 
> ls already showed characters that aren't part of a filename *before*
> this change:
> 
>   $ ls /tmp/a
>   a????????????  a????????????
> 
> Neither filename contains a question mark, and the filenames are
> actually not identical.

True, but that's because you created the file name in one locale and
tried to access it from another. I doubt that's going to happen to our
inexperienced hacker.

Even so, that actually reinforces my argument. My point was not about
adding random characters or changing some out, but about adding quoting
(forgive me for the imprecise wording, I hadn't had my coffee yet).

> One could argue that "ls" should give an error when it encounters any
> character that might need quoting instead of enabling quoting by
> default. (And this is probably also true when output does not go to a
> terminal: at least printing \n as part of a filename is pretty much
> always broken.)

Indeed.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Message #210 received at 813164-close@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: 813164-close@bugs.debian.org

Subject: Bug#813164: fixed in coreutils 8.25-2

Date: Tue, 16 Feb 2016 14:20:58 +0000

Source: coreutils
Source-Version: 8.25-2

We believe that the bug you reported is fixed in the latest version of
coreutils, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 813164@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Stone <mstone@debian.org> (supplier of updated coreutils package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Tue, 16 Feb 2016 09:02:12 -0500
Source: coreutils
Binary: coreutils mktemp realpath
Architecture: source amd64 all
Version: 8.25-2
Distribution: unstable
Urgency: medium
Maintainer: Michael Stone <mstone@debian.org>
Changed-By: Michael Stone <mstone@debian.org>
Description:
 coreutils  - GNU core utilities
 mktemp     - coreutils mktemp transitional package
 realpath   - coreutils realpath transitional package
Closes: 813164
Changes:
 coreutils (8.25-2) unstable; urgency=medium
 .
   * Disable default ls quoting for now to get the rest of 8.25 into testing.
     (Closes: #813164)
Checksums-Sha1:
 fdb300abfdf6ecef8d0baa4737f05a8da4417100 1925 coreutils_8.25-2.dsc
 cf12a644f43ef90440fde274e54d6bd6095ad6f1 21776 coreutils_8.25-2.debian.tar.xz
 16927be4984dc36ac1619033caf89541216374ea 2856996 coreutils_8.25-2_amd64.deb
 0d557754c09b07a337269471d4437e59f459dd61 436402 mktemp_8.25-2_all.deb
 0514be61287c2bac20bbc61ac054ce3a98eec21f 436396 realpath_8.25-2_all.deb
Checksums-Sha256:
 9909b8ad5d532cb3875d811711feaca819308fbbe5f1dc0542c64f6db6793c2d 1925 coreutils_8.25-2.dsc
 68aca1234eb219bf23099065cb0b1e2566b3ad7e80fdd977fe8bfe03b8fb0629 21776 coreutils_8.25-2.debian.tar.xz
 1bcb80761f5f49453763e197ff414e5f10e3d0832b16e93822863c03a6aadedb 2856996 coreutils_8.25-2_amd64.deb
 d2f2a10e61202cba0d8935ec7d0edaa68fd0c0174c339abe57c0c08372826981 436402 mktemp_8.25-2_all.deb
 f3c9c580ea9226480c79e2e7918d69d3ccdd6f17dece336591510711eb79aa47 436396 realpath_8.25-2_all.deb
Files:
 b3d907bc6f3952b67002564b33b414c5 1925 utils required coreutils_8.25-2.dsc
 49f84c7aea9499c4367f1e4ab36416f5 21776 utils required coreutils_8.25-2.debian.tar.xz
 0e693ddf86951d875a005859ed9aad2f 2856996 utils required coreutils_8.25-2_amd64.deb
 efa775839295b4103477be7d624bcae7 436402 oldlibs extra mktemp_8.25-2_all.deb
 9051346ecbf21474a1d81154e547ab2d 436396 oldlibs extra realpath_8.25-2_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJWwy6fAAoJEPYarNz6Ef/eWQYQAIcPO7y3V4IdoStbcPDXEU0Q
NwT/J6Ljdm3HJDyIhLRcwDllH2ll/CEpF7Omb3axZi2PcMH+pIQoiH+US6/F+pfr
MItEZvVYMLayq0Gy1cImsZvVJLeGSTZzpmIcGZINB8W9KEqGHFEuuYuZpOIBGJf3
+gJcAbS8qhWJWHCaRcwoH0FBXJVI5Wx1klqTBPWIjkhjM7JFj6FVsXsozrTTQx72
h4da1tlKRwwdDKsLEkuChd4/JQa6WOTINpLYraUKBld5m+QydV/gy6hV2oVnpo9f
kSX1RP+tuX02aPPS0bys12iphjPlHfaq1D7W4enD/rfkMG2NvQxgmFIKhiJ+Imdh
+xJUr5AKukQJGcyjYw1a7/OG+Oa9yxN+XXk2pK6qz7fI5Kodqis0c64RUr3oqViu
ssfPVCnNd5yJm0Ah3OkS915a9uDDSf2NtjXVWzAbZIlGbDZMHheIQflbE5b8YI87
tKQeGpXz1dKGwTLysCumgnxVx3OoXeu3i15LN8wRVNvugHjjmjJtKjRghADARe3e
RtVLIWH87m/qrpfFdu7Tl9W4sBOdb+fqbJXdmE7PK8WQBR93YtDAkVwJ0AYHl48c
D0BQ3iao/ilUOEroB3yYTIOZFFsD4JCtdO8gSOTRhl2ZdGyibauRiSPuQGu1OKt6
nVeLBZO2YvQGDqhqZ2xF
=Xu5+
-----END PGP SIGNATURE-----

Message #219 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Adam Borowski <kilobyte@angband.pl>

To: 813164@bugs.debian.org

Subject: broken again

Date: Tue, 3 Oct 2017 16:07:29 +0200

Control: found -1 8.28-1

Looks like broken quoting is back.  All the arguments still apply, and last
time the consensus was pretty strong.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄⠀⠀⠀⠀ agriculture, towns then cities.     -- whitroth on /.

Message #226 received at 813164-done@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Adam Borowski <kilobyte@angband.pl>, 813164-done@bugs.debian.org

Subject: Re: Bug#813164: broken again

Date: Tue, 3 Oct 2017 10:12:28 -0400

On Tue, Oct 03, 2017 at 04:07:29PM +0200, you wrote:
>Looks like broken quoting is back.  All the arguments still apply, and last
>time the consensus was pretty strong.

The change was intentional, and will remain.

Mike Stone

Message #235 received at 813164@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: 813164@bugs.debian.org

Subject: Re: Bug#813164: broken again

Date: Tue, 3 Oct 2017 11:16:38 -0400

For the record, I'll append what I said in 877582 so it's all in one 
place:

>You can call ls -N if desired or set QUOTING_STYLE=literal. I overrode
>the default until such a time as a version of coreutils supporting all
>of the new semantics/options reached stable, so that users could
>configure stable and unstable debian systems consistently. That
>milestone has been reached, so the package will no longer override the
>upstream default.

>It's also worth noting that the implementation evolved significantly
>from the initial release in 8.25, based on user feedback. The major
>functional issues have been addressed, so what remains is user
>preference--for which there are configuration knobs.

Send a report that this bug log contains spam.