[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22696: ls output changes considered unacceptable
From: |
Ruediger Meier |
Subject: |
bug#22696: ls output changes considered unacceptable |
Date: |
Tue, 16 Feb 2016 19:48:59 +0100 |
User-agent: |
KMail/1.9.10 |
On Tuesday 16 February 2016, Paul Eggert wrote:
> On 02/16/2016 08:58 AM, Ruediger Meier wrote:
> > Terminal output should be human readable not machine readable.
>
> Sure, but under the old way of doing things, terminal output *wasn't*
> human-readable. For example:
If the file name _is_ readable at all, then it was printed in a more
readable way. This is a regression.
> $ ls
> a?b a?b axb c d e
> $ rm a?b c d
Of course, non-printable chars are not correctly printed. Other tools
like less, more, texteditor, webbrowser don't print non-printable
chars. Why ls?
> rm: cannot remove 'd': No such file or directory
Who says that ls outout should be copy/pastable (!_into_shell_only_!).
It's a corner case. That's why we have --quoting-style. That's fine as
long as it's not the default.
And why is `ls | grep "files to copy/paste"' not copy/pastable by
default then? This makes no sense.
No other command is printing filenames as annyoing as ls. What about
readlink, basename, mktemp ...
Why they don't have a terminal mode too? I copy paste many other's
command output very very often every day. Now ls is the only one which
wants to help me with it ... but I hate it. I also copy/paste file
names into emails, chat or commit messages ... not only into a _shell_
commandline.
At least you could have done it human readable like git, for example:
$ touch $'AAA\nBBB'
$ touch $'AAA\x05BBB'
$ touch "other's"
$ git add *
$ git st
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: "AAA\005BBB"
# new file: "AAA\nBBB"
# new file: other's
> The new behavior is much more readable and understandable. Of course
> this is a contrived example (created via:
>
> touch 'a
> b' 'a?b' axb c 'd e'
>
> )
> , but it's similar to situations that I run into all the time when
> teaching newbies.New users should be better off with the new
> approach, in ordinary interactive use.
No! IMO Newbies should learn (most painful as possible!) that non-ascii
filenames sucks. :) Maybe ls shouldn't show them at all by default ;)
If they want to use strange file names than they should use dolphin or
konqueror. (Deleting files by click, no copy/pasting needed).
> I didn't comment on the original change, because I thought it was a
> no-brainer.
Please revert it.
> Yes, there is a backward-compatibility issue, but users
> worried about compatibility should be using portable POSIX file names
> anyway, and 'ls' hasn't changed its behavior with portable file
> names.
I can't control what stupid file names come from other users or
downloaded from the internet.
cu,
Rudi
- bug#22698: ls output changes considered unacceptable, Jason A. Donenfeld, 2016/02/16
- bug#22696: ls output changes considered unacceptable, Bernhard Voelker, 2016/02/16
- bug#22696: ls output changes considered unacceptable, Bernhard Voelker, 2016/02/16
- bug#22696: ls output changes considered unacceptable, Ruediger Meier, 2016/02/16
- bug#22696: ls output changes considered unacceptable, Jon Stanley, 2016/02/16
- bug#22696: ls output changes considered unacceptable, Ruediger Meier, 2016/02/16
- bug#22696: ls output changes considered unacceptable, Assaf Gordon, 2016/02/16
- bug#22696: ls output changes considered unacceptable, Paul Eggert, 2016/02/16
- bug#22696: ls output changes considered unacceptable, Ruediger Meier, 2016/02/16
- bug#22696: ls output changes considered unacceptable, isabella parakiss, 2016/02/16
- bug#22696: ls output changes considered unacceptable, Mike Frysinger, 2016/02/16