[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input
From: |
L A Walsh |
Subject: |
bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input |
Date: |
Mon, 09 Jan 2017 11:38:29 -0800 |
User-agent: |
Thunderbird |
Paul Eggert wrote:
On 01/09/2017 10:48 AM, L A Walsh wrote:
That's not what I'm used to:
I couldn't parse your email.
---
1) I ran the ls command on a directory, shows 4 columns
(that were in color).
Ishtar:/tmp/tmp> ls
12345678 a.exe* cccccccccccc.tar ssh-3LKwkRvOQM/
UiGUI_log_20161216-1442.htm bbbbbbbbb.gz ddddddddddddddd tall/
2) Next I ran the same ls command through more (really 'less' -- something
set @ distro level, but found convenient, so kept it). Output is
identical.
Ishtar:/tmp/tmp> ls |more
12345678 a.exe* cccccccccccc.tar ssh-3LKwkRvOQM/
UiGUI_log_20161216-1442.htm bbbbbbbbb.gz ddddddddddddddd tall/
3) Then I ran the same command and sent it to a file (which I attached
to the email) and ran 'wc' on it -- which showed it had
2 lines and 8 "words" (filenames in this case).
Ishtar:/tmp/tmp> ls >../tmpdir.txt
Ishtar:/tmp/tmp> wc ../tmpdir.txt
2 8 235 ../tmpdir.txt
I was describing the common behavior in BSD
and GNU/Linux for ages, like this:
$ touch a b
$ ls
a b
$ ls | more
a
b
----
When I do the same, I get this:
ls
a b
ls | more
a b
Which is how it has been for over 15 years on linux on my machines.
If my problem is that the 'ls' listing scrolled off the screen
too fast for me to read, then the "default" behavior (that you
describe) doesn't seem well thought out. If a user couldn't
read it in multi-column mode, what would prompt anyone to think that
they would automatically want it in 1-column mode when they
put it through a pager -- doesn't make sense.
If I wanted 1 column format, why wouldn't I use "-1".
That's the entire purpose of the switch.
Again, I state that showing different output through a pager vs.
what was shot out to the screen could allow a security problem
in the form of a stenographic attack.
While dumping the output to a screen, maybe, a SW hack couldn't
be covered up, but if they altered the sources of 'more/less',
to hide their tracks, it would be noticeably harder to find.
It's not good practice, IMO, to be altering output based on
what (or who) is reading it (at least not by default).
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/07
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Andreas Schwab, 2017/01/08
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Paul Eggert, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Paul Eggert, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input,
L A Walsh <=
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Eric Blake, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Paul Eggert, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Eric Blake, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Eric Blake, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Eric Blake, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, L A Walsh, 2017/01/09
- bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input, Pádraig Brady, 2017/01/09