Re: [PATCH 1/2] dd: the word BLOCKS no longer occurs in the help text
On 08/16/2012 06:45 PM, Benno Schulenberg wrote:
Hi,
The help text of dd now mentions that the word BLOCKS can
be replaced with something. But the word BLOCKS does not
occur any longer in the entire help text.
On 08/16/2012 10:30 PM, Bruce Dubbs wrote:
When we run the tests, we can change our procedures to set any TZ needed.
Could you please try it with TZ='EST5EDT,M3.2.0,M11.1.0'?
If that works, we can change the test program to use that
TZ value by default.
Jim Meyering wrote:
Jim Meyering wrote:
...
In case anyone is chomping at the bit, here's a preliminary patch:
Here's a smaller test case that appears to be host/nproc-independent:
It should print two lines: 1, then 7.
Without this patch, it prints only 7.
(yes 7|head -11; echo
On 08/17/2012 12:00 PM, Jim Meyering wrote:
I want to make a release with this fix as soon as possible.
Since I'm making this a mostly-bug-fix release, the du and md5 --tag
changes will have to wait for 8.20.
However, I'll be happy to apply documentation-correcting changes
if someone would
Hi there,
But yes, the main thing is for someone to contribute
correct, easy-to-maintain, and efficient code.
Just for the record, if any day somebody wants to attend this
I just noticed, that the tr from 9base can handle utf-8 correctly.
9base is a unix-port of the plan9 utils:
Paul Eggert wrote:
On 08/16/2012 10:30 PM, Bruce Dubbs wrote:
When we run the tests, we can change our procedures to set any TZ needed.
Could you please try it with TZ='EST5EDT,M3.2.0,M11.1.0'?
If that works, we can change the test program to use that
TZ value by default.
I found two
On 08/17/2012 10:46 AM, Bruce Dubbs wrote:
I've never seen the M parameters in TZ before. What do they do?
They specify the time zone rules directly, without consulting
the tz database. Unlike the tz database, they're specified by
POSIX, so they should be more portable. Also, POSIX says they
Paul Eggert wrote:
On 08/17/2012 10:46 AM, Bruce Dubbs wrote:
I've never seen the M parameters in TZ before. What do they do?
They specify the time zone rules directly, without consulting
the tz database. Unlike the tz database, they're specified by
POSIX, so they should be more portable.
On 08/16/2012 02:03 PM, Jim Meyering wrote:
* src/sort.c (saved_line): New static/global, renamed and moved from...
(write_unique): ...here.
I see a couple of problems with this patch. Pedantically,
the behavior of 'overlap' is undefined on hosts that
use a segmented architecture, because '='
Paul Eggert wrote:
On 08/16/2012 02:03 PM, Jim Meyering wrote:
* src/sort.c (saved_line): New static/global, renamed and moved from...
(write_unique): ...here.
I see a couple of problems with this patch. Pedantically,
the behavior of 'overlap' is undefined on hosts that
use a segmented
Jim Meyering wrote:
...
That sort -u can cause data loss is a big deal.
I want to make a release with this fix as soon as possible.
Since I'm making this a mostly-bug-fix release, the du and md5 --tag
changes will have to wait for 8.20.
However, I'll be happy to apply documentation-correcting
On 08/17/2012 12:36 PM, Jim Meyering wrote:
The first time the safe_text buffer is allocated
it will have to be disjoint from the line.text buffer
and from the buffer into which we're about to fread.
Thereafter, regardless of reallocation, overlap should
always be false.
I haven't thought it
Paul Eggert wrote:
On 08/17/2012 12:36 PM, Jim Meyering wrote:
The first time the safe_text buffer is allocated
it will have to be disjoint from the line.text buffer
and from the buffer into which we're about to fread.
Thereafter, regardless of reallocation, overlap should
always be false.
On 08/17/2012 12:53 PM, Jim Meyering wrote:
safe_text is initially NULL and we enter that block
only when we're about to fread into a buffer that overlaps
the current saved_line.text buffer.
Sorry, I wasn't clear enough. I was worried about the
case when saved_line.text does not overlap the
Paul Eggert wrote:
On 08/17/2012 12:53 PM, Jim Meyering wrote:
safe_text is initially NULL and we enter that block
only when we're about to fread into a buffer that overlaps
the current saved_line.text buffer.
Sorry, I wasn't clear enough. I was worried about the
case when saved_line.text
OK, I scratched my head for a bit and came up with the following
further patch, which addresses the issues that I mentioned.
From ac405d343c379096c7ed51b481d5ed08ee18d6e0 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Fri, 17 Aug 2012 13:26:00 -0700
Subject: [PATCH] sort:
Paul Eggert wrote:
OK, I scratched my head for a bit and came up with the following
further patch, which addresses the issues that I mentioned.
...
Subject: [PATCH] sort: simpler fix for sort -u data-loss bug
* src/sort.c (overlap): Remove.
(fillbuf): Do not try to copy saved lines, as that
Paul Eggert wrote:
OK, I scratched my head for a bit and came up with the following
further patch, which addresses the issues that I mentioned.
Subject: [PATCH] sort: simpler fix for sort -u data-loss bug
* src/sort.c (overlap): Remove.
(fillbuf): Do not try to copy saved lines, as that is
On 08/17/2012 10:40 PM, Jim Meyering wrote:
I've adjusted your commit log to look like this.
Is that ok with you?
Sure, that all looks good. Thanks for doing that.
19 matches
Mail list logo
