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
Since the sort options -M and -n are incompatible, there appears to be
no easy way to sort log files.
/Lars
tags 10019 + moreinfo notabug
thanks
Lars Noodén wrote:
> Since the sort options -M and -n are incompatible, there appears to
> be no easy way to sort log files.
Unfortunately your bug report doesn't include enough information to
understand what you are reporting. It does not make sense that you
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 roo
On 11/11/2011 01:55 PM, Lars Noodén wrote:
> Since the sort options -M and -n are incompatible, there appears to be no
> easy way to sort log files.
Sorry if you get a dupe.
My last was sent to 10019-done which I think crossed with Bob's
mail to the same address and was dropped?
I'm not even sure
Hi All,
> Date: Thu, 10 Nov 2011 16:10:27 -0800
> From: egg...@cs.ucla.edu
> To: ebl...@redhat.com
> CC: ianbruntl...@hotmail.com; 10...@debbugs.gnu.org
> Subject: Re: bug#10013: man ls
>
> On 11/10/11 13:33, Eric Blake wrote:
> > +The @command{ls} program stands for ``list sorted''.
>
> I'm so
Hi,
I'm reviewing some old bugs reported to Debian and found this one interesting.
The problem seems to be that cp -l won't work if the file exists, and the -i
option
won't "force" (work as if the user has given a -f option) the deletion of the
destination file, to make the link work.
A small t
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
On 11/11/2011 10:38 AM, Ian Bruntlett wrote:
> My source was James O. Coplien at an ACCU conference in Oxford some
> years ago. I didn't want to drop names.
Completely understandable. Coplien is a good source,
but he was at Bell Labs lng after "ls" was created.
I'd like something a little clos
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
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
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
tag 10019 moreinfo
thanks
On 11/11/2011 06:55 AM, Lars Noodén wrote:
> Since the sort options -M and -n are incompatible, there appears to be
> no easy way to sort log files.
Not true, if you use -k to separate the sort into non-overlapping keys.
Please post an example of 2 or 3 lines you'd like
Hello,
On GNU, processes can have zero or more UIDs/GIDs. In the case of a
process with zero UIDs, for instance, ‘getuid’ returns -1 and sets
ERRNO [0] (as an extension to POSIX [1].)
Currently ‘id’ would print (unsigned int) -1 as the UID in that case,
whereas it should rather print an error.
On 11/11/11 7:34 PM, Eric Blake wrote:
[snip]
I'm guessing that there is no bug in sort, but I'll wait for more
info from you of an actual sample of the lines you want sorted, what
you tried, what you got, and a comparison to what you wanted, before
declaring this as not a bug.
There is no bug
On 11/11/2011 11:36 AM, Lars Noodén wrote:
> An additional line of clarification would go a long way in
> making this very useful capability more available.
Hmm, what line would that be? We do have a tradeoff
among clarity, completeness, and conciseness here.
By the way, the info page (which is
On 11/11/2011 09:55 AM, Pádraig Brady wrote:
> sort -b -k4.9,4.12 -k4.5b,4.7Mb -k4.2,4.3 -k4.14,4 access_log
Whew! That's pretty subtle. Do you observe
a significant performance improvement by avoiding
-n? I'm asking partly because the manual does it this way:
sort -t ' ' -k 4.9n -k 4.5M -k
Ludovic Courtès wrote:
> On GNU, processes can have zero or more UIDs/GIDs. In the case of a
> process with zero UIDs, for instance, ‘getuid’ returns -1 and sets
> ERRNO [0] (as an extension to POSIX [1].)
>
> Currently ‘id’ would print (unsigned int) -1 as the UID in that case,
> whereas it shoul
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 --kibi
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/2011 07:50 PM, Paul Eggert wrote:
> On 11/11/2011 09:55 AM, Pádraig Brady wrote:
>> sort -b -k4.9,4.12 -k4.5b,4.7Mb -k4.2,4.3 -k4.14,4 access_log
> Whew! That's pretty subtle. Do you observe
> a significant performance improvement by avoiding
> -n? I'm asking partly because the manual
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
On 11/10/11 13:36, Eric Blake wrote:
> I can live with it.
OK, thanks, I changed "10GB" to "10MB" since it might refer to a RAM
quantity I suppose, and pushed it:
* src/system.h (emit_size_note): Reword for clarity.
See discussion in Bug#9939.
diff --git a/src/system.h b/src/system.h
index 926def
25 matches
Mail list logo
