Paul Eggert wrote:
On 11/11/11 13:10, Jim Meyering wrote:
Do you feel like writing the patch?
Sure. I wrote and pushed the following.
The test case isn't elegant, but at least it catches the bug.
That was quick. Thanks!
Eric Blake wrote:
On 11/10/2011 04:35 PM, Alan Curry wrote:
I mentioned this already in the bug#9939 thread, but nobody replied and it's
really a separate issue so here's an independent report.
This behavior:
$ ls -l /bin/ls
-rwxr-xr-x 1 root root 107124 Feb 8 2011 /bin/ls
$ ls -lk
Jim Meyering wrote:
Eric Blake wrote:
On 11/10/2011 04:35 PM, Alan Curry wrote:
I mentioned this already in the bug#9939 thread, but nobody replied and it's
really a separate issue so here's an independent report.
This behavior:
$ ls -l /bin/ls
-rwxr-xr-x 1 root root 107124 Feb 8 2011
On 11/11/2011 10:30 AM, Jim Meyering wrote:
I don't like the idea of printing a byte count there when
--block-size=... takes effect. Does anyone else have an opinion?
Sorry, I've lost context. Are you talking about
the output of ls -ls --block-size=1?
Currently it starts with something like
Paul Eggert wrote:
On 11/11/2011 10:30 AM, Jim Meyering wrote:
I don't like the idea of printing a byte count there when
--block-size=... takes effect. Does anyone else have an opinion?
Sorry, I've lost context. Are you talking about
the output of ls -ls --block-size=1?
Currently it
Eric Blake wrote:
On 11/11/2011 11:30 AM, Jim Meyering wrote:
+++ b/src/ls.c
@@ -3030,9 +3030,7 @@ gobble_file (char const *name, enum filetype type,
ino_t inode,
{
char buf[LONGEST_HUMAN_READABLE + 1];
uintmax_t size = unsigned_file_size
On 11/11/2011 10:36 AM, Eric Blake wrote:
Are you proposing that --block-size keep the current behavior, and that
-k no longer be a synonym for --block-size=1k but instead becomes a new
long option?
Makes sense to me
That sort of thing makes sense to me too.
I assume --block-size should
The long option shouldn't be --kilobyte, since ls -k means
1024 not 1000. So I suppose it should be --kibibyte.
It's a little tricky, since -k means --block-size=1K
for df and du as well, and I assume this won't change,
since df -k and du -k conform to POSIX. (Surely there's
no need to add
Paul Eggert wrote:
The long option shouldn't be --kilobyte, since ls -k means
1024 not 1000. So I suppose it should be --kibibyte.
It's a little tricky, since -k means --block-size=1K
for df and du as well, and I assume this won't change,
since df -k and du -k conform to POSIX. (Surely
Jim Meyering writes:
I'm thinking of making -k comply, but letting any block-size
specification (via --block-size= or an envvar) override that
to give the behavior we've seen for the last 9 years.
Wow, look what I stirred up.
If it's been like this for 9 years, it's been broken for 9
On 11/11/2011 09:06 PM, Paul Eggert wrote:
The long option shouldn't be --kilobyte, since ls -k means
1024 not 1000. So I suppose it should be --kibibyte.
It's a little tricky, since -k means --block-size=1K
for df and du as well, and I assume this won't change,
since df -k and du -k
On 11/11/11 13:10, Jim Meyering wrote:
Do you feel like writing the patch?
Sure. I wrote and pushed the following.
The test case isn't elegant, but at least it catches the bug.
ls: -k no longer affects -l's file sizes
This fixes an incompatibility with POSIX 2008 and with BSD.
Problem reported
I mentioned this already in the bug#9939 thread, but nobody replied and it's
really a separate issue so here's an independent report.
This behavior:
$ ls -l /bin/ls
-rwxr-xr-x 1 root root 107124 Feb 8 2011 /bin/ls
$ ls -lk /bin/ls
-rwxr-xr-x 1 root root 105 Feb 8 2011 /bin/ls
is awful. -k
On 11/10/2011 04:35 PM, Alan Curry wrote:
I mentioned this already in the bug#9939 thread, but nobody replied and it's
really a separate issue so here's an independent report.
This behavior:
$ ls -l /bin/ls
-rwxr-xr-x 1 root root 107124 Feb 8 2011 /bin/ls
$ ls -lk /bin/ls
-rwxr-xr-x 1 root
14 matches
Mail list logo
