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
