GNU bug report logs - #14525
ls -k produced no size, ls -lk lists in bytes? What's up w/k?

Previous Next

Full log

View this message in rfc822 format

From: Linda Walsh <coreutils <at> tlinx.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 14525 <at> debbugs.gnu.org
Subject: bug#14525: ls -k produced no size, ls -lk lists in bytes?  What's up w/k?
Date: Thu, 06 Jun 2013 18:14:58 -0700

Eric Blake wrote:
>>> Block size defaults can be overridden by an explicit
>>> `--block-size=SIZE' option.  The `-k' option is equivalent to
>>> `--block-size=1K', which is the default unless the `POSIXLY_CORRECT'
>>> environment variable is set. 




Pádraig Brady wrote:
> Since coreutils 8.15 the behavior was changed to be more consistent
> with other systems and POSIX:


> which, while still true for du and df, is now false for ls.

---
So Gnu 'ls' was changed to make it less consistent with other Gnu
utilities like 'du' and 'df'?

I understand that part about it being more consistent with some other
'stuff' , that I am not exposed nor use, but comparing it with the
stuff I do use ('du' and 'df'), it doesn't seem like a great way to
go...

Is 'k' going to be reused for something else?  If not, why wasn't it
just left alone?  Was it really bugging people that much to be consistent
with 'du' and 'df'?  or are they next in line for making 1-2 char easy-to-use
options into 15 character pains to type?

So much of this is about ease of use -- which is a good thing.. portability for
shell scripts is fine, but is 'k' scheduled for being used for something else?

Otherwise, it seems like someone's just changing things for no real good reason.

Previous Next

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