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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14525 in the body.
You can then email your comments to 14525 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Subject: ls -k produced no size, ls -lk lists in bytes?  What's up w/k?
Date: Fri, 31 May 2013 18:02:00 -0700

in Coreutils 8.21.1.1 (x86_64) on snoozy
When I type in ls -k, I get a small listing (filenames only horizontally)
(and no sizes).
When I type in ls -lk, I get a long listing -- but it isn't using K, but
bytes.

:-(.

Why k no worky?

I'd think:
1) ls -k should display the file size in k as ls -s display blocks.
2) ls -sk would display allocated size in k (which it may do?)
and
3)ls -l would display sizes in k.

Am I missing something about why 'k' doesn't work in 1 & 3?

Actually ls -s acts like ls -sk -- doesn't display blocks but -k-

Isn't a block 512B?

Message #8 received at 14525 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 14525 <at> debbugs.gnu.org
Subject: Re: bug#14525: ls -k produced no size, ls -lk lists in bytes?  What's
	up w/k?
Date: Sat, 01 Jun 2013 16:53:13 +0100

unarchive 11794 13902
forcemerge 11794 13902 14525
stop

On 06/01/2013 02:02 AM, Linda Walsh wrote:
> 
> in Coreutils 8.21.1.1 (x86_64) on snoozy
> When I type in ls -k, I get a small listing (filenames only horizontally)
> (and no sizes).
> When I type in ls -lk, I get a long listing -- but it isn't using K, but
> bytes.
> 
> :-(.
> 
> Why k no worky?

Since coreutils 8.15 the behavior was changed to be more consistent
with other systems and POSIX:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=448718

thanks,
Pádraig.

Message #11 received at 14525 <at> debbugs.gnu.org (full text, mbox):

From: "Linda A. Walsh" <lkml <at> tlinx.org>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 14525 <at> debbugs.gnu.org
Subject: Re: bug#14525: ls -k produced no size,
	ls -lk lists in bytes?  What's up w/k?
Date: Sat, 01 Jun 2013 09:20:55 -0700

Pádraig Brady wrote:
> On 06/01/2013 02:02 AM, Linda Walsh wrote:
>> in Coreutils 8.21.1.1 (x86_64) on snoozy
>> When I type in ls -k, I get a small listing (filenames only horizontally)
>> (and no sizes).
>> When I type in ls -lk, I get a long listing -- but it isn't using K, but
>> bytes.
> 
> Since coreutils 8.15 the behavior was changed to be more consistent
> with other systems and POSIX:
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=448718
----
	What replaced it?

	I mean it doesn't do something *different*, it just ignores it.
So does this mean that to be POSIX compatible all the utils will have to be
dumbed down and have functionality removed?

	If you needed it for something else, or something else replaced it --
that's one thing, but it seems like the trend is just removing added functionality
that gnu-linux users have come to enjoy...

	Do we need a new non-posix core utils that keeps
the extended functionality?  I don't understand why you guys are butchering
the gnu products and removing features to comply with posix... it was never
intended to be a highest common denominator, but a lowest...

Message #14 received at 14525 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Linda A. Walsh" <lkml <at> tlinx.org>
Cc: 14525 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#14525: ls -k produced no size, ls -lk lists in bytes?  What's
	up w/k?
Date: Sat, 01 Jun 2013 14:35:24 -0700

On 06/01/2013 09:20 AM, Linda A. Walsh wrote:
> 	What replaced it?
> 
> 	I mean it doesn't do something *different*, it just ignores it.

I'm not sure what behavior you're asking for, but if you want
the old behavior of -k, you can use the --block-size=1KiB
option.  So no functionality was lost.

-k (and --block-size=1KiB) affects only the block size of
displayed values; it doesn't affect the choice of which
values to display.

Message #17 received at 14525 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 14525 <at> debbugs.gnu.org
Subject: Re: bug#14525: ls -k produced no size,
	ls -lk lists in bytes?  What's up w/k?
Date: Sat, 01 Jun 2013 14:54:32 -0700

Paul Eggert wrote:
> On 06/01/2013 09:20 AM, Linda A. Walsh wrote:
>> 	What replaced it?
>>
>> 	I mean it doesn't do something *different*, it just ignores it.
> 
> I'm not sure what behavior you're asking for, but if you want
> the old behavior of -k, you can use the --block-size=1KiB
> option.  So no functionality was lost.
> 
> -k (and --block-size=1KiB) affects only the block size of
> displayed values; it doesn't affect the choice of which
> values to display.
====
Maybe now, but that's not what used to be the case.

ls -k was consistent, with, say, 'du -k'.

I just checked, and ls -kl displayed sizes in terms of 'K'.

What switch(es) are supposed to be used to choose what units to display
sizes on the long listing?

I know the "-h" displays sizes using variable units,
but if I want to have it display all of the sizes in terms
of 'K' or 'M' or (not likely useful, but 'G' or 'T'), how
do I do it?

I do recall and note that the old display didn't display
units... but having short-hands for displaying the sizes
in a fixed-human size (like K/M... etc) would be a great
replacement...though w/o the units would give the same functionality
as before.

If 'k' doesn't have it, does posix mandate that the user can't
choose what unit to display things in?  Alot of non-posix features
happened because posix had deficits and it was a 'minimal, required
feature set' -- it wasn't necessarily a good user-interface.

It seems like Gnu has sold off to corporate interests in removing features
that exceeded posix... why, or what am I mising?  I see no sense in
dumbing down features that Gnu had over posix.  Let posix catch up!

If no one sets a better standard, posix will never improve.

Message #20 received at 14525 <at> debbugs.gnu.org (full text, mbox):

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

[Message part 1 (text/plain, inline)]

On 06/01/2013 03:54 PM, Linda Walsh wrote:
> I know the "-h" displays sizes using variable units,
> but if I want to have it display all of the sizes in terms
> of 'K' or 'M' or (not likely useful, but 'G' or 'T'), how
> do I do it?

'ls --block-size=1k' or 'ls --block-size=1M'

> If 'k' doesn't have it, does posix mandate that the user can't
> choose what unit to display things in?

POSIX can only mandate what portable uses are limited to.  You are
correct that there is no portable way, via POSIX options alone, to make
ls change what units it displays in, other than what POSIX requires of
'-k' (which affects only the -s column and the per-directory summary).
But POSIX does not (and cannot) mandate against extensions, and we have
not removed any of coreutils' extensions - we merely removed -k as a
synonym of the extension --block-size=..., because the POSIX
specification of -k is incompatible with the --block-size= extension
semantics that we did not change.  If you think there is an extension
missing in ls to display something that you need, feel free to write a
patch to provide that extension - we have long desired to have a
--format option that would let you choose which pieces of information to
display and in what order.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #23 received at 14525 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#14525: ls -k produced no size,
	ls -lk lists in bytes?  What's up w/k?
Date: Sat, 01 Jun 2013 18:25:11 -0700

Eric Blake wrote:
  If you think there is an extension
> missing in ls to display something that you need, feel free to write a
> patch to provide that extension 
====
Actually it's a desire to have what Used to be there before...


Astarte:law> ll *.iso
-rw-rw-r-- 1 734646272 2011-01-13 07:45 OMSA64-CentOS55-x86_64-LiveCD.iso
               ^^ size in bytes...
Astarte:law> ll -k *.iso
-rw-rw-r-- 1 717428 2011-01-13 07:45 OMSA64-CentOS55-x86_64-LiveCD.iso
                ^^ size in K....
Astarte:law> ll --block-size=M *.iso
-rw-rw-r-- 1 701M 2011-01-13 07:45 OMSA64-CentOS55-x86_64-LiveCD.iso
              ^^^ and size in Megabytes -- even with the 'M'...

I could send you a patch from 7.1, but you probably already have
a more recent version that doesn't have functionality removed?

Message #26 received at 14525 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 14525 <at> debbugs.gnu.org
Subject: Re: bug#14525: ls -k produced no size, ls -lk lists in bytes?  What's
	up w/k?
Date: Sun, 02 Jun 2013 11:47:50 -0700

On 06/01/2013 02:54 PM, Linda Walsh wrote:
> ... removing features that exceeded posix

As I explained to you in my previous message, no features
were removed.  Merely the option syntax was changed.

> What switch(es) are supposed to be used to choose what units to display
> sizes on the long listing?

The --block-size option.  See:

http://www.gnu.org/software/coreutils/manual/coreutils.html#Block-size

Coreutils already has all the features that you asked for
in your email.

Message #29 received at 14525 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 14525 <at> debbugs.gnu.org
Subject: Re: bug#14525: ls -k produced no size,
	ls -lk lists in bytes?  What's up w/k?
Date: Sun, 02 Jun 2013 12:04:16 -0700

Paul Eggert wrote:
> On 06/01/2013 02:54 PM, Linda Walsh wrote:
>> ... removing features that exceeded posix
> 
> As I explained to you in my previous message, no features
> were removed.  Merely the option syntax was changed.


Ah...I'm sorry, I misunderstood.  I thought I read that
it didn't apply to the long listing format.

My bad for not reading carefully enough.
Thank you for your patience...

Message #32 received at 14525 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 14525 <at> debbugs.gnu.org, Linda Walsh <coreutils <at> tlinx.org>
Subject: Re: bug#14525: ls -k produced no size, ls -lk lists in bytes?  What's
	up w/k?
Date: Tue, 04 Jun 2013 13:40:36 -0600

[Message part 1 (text/plain, inline)]

On 06/02/2013 12:47 PM, Paul Eggert wrote:
> On 06/01/2013 02:54 PM, Linda Walsh wrote:
>> ... removing features that exceeded posix
> 
> As I explained to you in my previous message, no features
> were removed.  Merely the option syntax was changed.
> 
>> What switch(es) are supposed to be used to choose what units to display
>> sizes on the long listing?
> 
> The --block-size option.  See:
> 
> http://www.gnu.org/software/coreutils/manual/coreutils.html#Block-size
> 
> Coreutils already has all the features that you asked for
> in your email.

I just noticed that we DO have a doc bug; in 'info coreutils "Block
size"', we incorrectly claim:

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

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

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #35 received at 14525 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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.

Message #38 received at 14525 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 14525 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Linda Walsh <coreutils <at> tlinx.org>
Subject: Re: bug#14525: ls -k produced no size, ls -lk lists in bytes?  What's
 up w/k?
Date: Tue, 26 Nov 2013 15:53:58 +0000

[Message part 1 (text/plain, inline)]

On 06/04/2013 08:40 PM, Eric Blake wrote:
> On 06/02/2013 12:47 PM, Paul Eggert wrote:
>> On 06/01/2013 02:54 PM, Linda Walsh wrote:
>>> ... removing features that exceeded posix
>>
>> As I explained to you in my previous message, no features
>> were removed.  Merely the option syntax was changed.
>>
>>> What switch(es) are supposed to be used to choose what units to display
>>> sizes on the long listing?
>>
>> The --block-size option.  See:
>>
>> http://www.gnu.org/software/coreutils/manual/coreutils.html#Block-size
>>
>> Coreutils already has all the features that you asked for
>> in your email.
> 
> I just noticed that we DO have a doc bug; in 'info coreutils "Block
> size"', we incorrectly claim:
> 
>>> 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. 
> 
> which, while still true for du and df, is now false for ls.
> 

Doc update attached.

thanks,
Pádraig.

[ls-k-docs.diff (text/x-patch, attachment)]

Message #41 received at 14525 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>, 
 Eric Blake <eblake <at> redhat.com>
Cc: 14525 <at> debbugs.gnu.org, Linda Walsh <coreutils <at> tlinx.org>
Subject: Re: bug#14525: ls -k produced no size, ls -lk lists in bytes?  What's
 up w/k?
Date: Tue, 26 Nov 2013 12:29:51 -0800

Looks good to me; thanks.

Message #44 received at 14525 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 14525 <at> debbugs.gnu.org
Subject: Re: bug#14525: ls -k produced no size, ls -lk lists in bytes? What's
 up w/k?
Date: Thu, 18 Oct 2018 18:39:57 -0600

tags 14525 notabug
close 14525
stop

(triaging old bugs)

On 26/11/13 08:53 AM, Pádraig Brady wrote:
> 
> Doc update attached.
> 

With the update pushed, I'm closing this bug.

https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=17bce8c63e9e0f85b48ca62b63413ce9102af5c1

regards,
 - assaf

Previous Next

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