GNU bug report logs - #25388
ls-quotes: kills existing scripts reading "ls" -1 as input

Previous Next

Package: coreutils;

Reported by: L A Walsh <coreutils <at> tlinx.org>

Date: Sun, 8 Jan 2017 03:53:01 UTC

Severity: normal

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: L A Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, 25388 <at> debbugs.gnu.org
Subject: bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input
Date: Mon, 09 Jan 2017 11:38:29 -0800

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).






This bug report was last modified 6 years and 160 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.