Hi,
The previous version did not warn if the final record in a file was
out of order and `--check-order' was not in effect.
Thanks,
Bo
From dc34eed9e6ee34f473a8d74b98bccaf082fe79c2 Mon Sep 17 00:00:00 2001
From: Bo Borgerson [EMAIL PROTECTED]
Date: Sun, 20 Apr 2008 21:24:16 -0400
Subject:
Elbert Pol [EMAIL PROTECTED] wrote:
Hoi Jim, and the rest
I try to debug some things for os2 and it seems a hell of a job :(
Espicely if you have no backgrounds about the debugger.
But i saw newer Coreutils 6.11 i thought i try and the configuratie
went smootly this time :P
Then i did
Bruno Haible [EMAIL PROTECTED] wrote:
Jim Meyering wrote:
As for i18n, some students nearly took on the project of implementing a
palatable solution recently, but that's been deferred for a few months.
Interesting... In 2001 you set out the following requirements for such
a solution:
-
Mike Frysinger [EMAIL PROTECTED] wrote:
On Sunday 20 April 2008, Jim Meyering wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
On Sunday 20 April 2008, Mike Frysinger wrote:
On Sunday 20 April 2008, Jim Meyering wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
has work on merging Andreas'
If by unknown you mean nameless, that's not what the patch does.
Such a patch would not even have been considered.
I agree that hiding this information in some cases might not be
optimal, but the main problem is that through this the 'groups'
command becomes utterly useless and confused quite
Jim Meyering wrote:
- Processing in unibyte locales should not become significantly slower
than before.
- Code duplication should be avoided, for maintainability.
- Macros which expand to one thing in the multibyte case and to another
thing for the unibyte case are not
Bruno Haible [EMAIL PROTECTED] wrote:
Jim Meyering wrote:
- Processing in unibyte locales should not become significantly slower
than before.
- Code duplication should be avoided, for maintainability.
- Macros which expand to one thing in the multibyte case and to another
Bruno Haible wrote:
Jim Meyering wrote:
- Processing in unibyte locales should not become significantly slower
than before.
- Code duplication should be avoided, for maintainability.
- Macros which expand to one thing in the multibyte case and to another
thing for the unibyte
Hi,
Pádraig pointed out that there's no reason to copy data around here.
This version avoids the copies.
Thanks Pádraig,
Bo
From 49ec3883efc8a89e8a4260f25bb50178aced1be4 Mon Sep 17 00:00:00 2001
From: Bo Borgerson [EMAIL PROTECTED]
Date: Sun, 20 Apr 2008 21:24:16 -0400
Subject: [PATCH] Make
Bo Borgerson [EMAIL PROTECTED] wrote:
Pádraig pointed out that there's no reason to copy data around here.
This version avoids the copies.
Thanks Pádraig,
Thanks from me, too.
If you guys can help by reviewing others' changes, that would help me.
In the run-up to 6.11, quite a few large
Hoi Jim,
I used the lzma and after that i untar the tar file
I attach the log
Hope it's fixable :)
Jim Meyering wrote:
Elbert Pol[EMAIL PROTECTED] wrote:
Hoi Jim, and the rest
I try to debug some things for os2 and it seems a hell of a job :(
Espicely if you have no backgrounds about
Hello,
I have been using the 'wc' program (version 5.97) to manually verify
some counts outputted by a component part of an application I am
developing.
I noticed that:
echo 12345 | wc -m
Gives me '6' as output. But I don't entirely understand why.
On multi-line input 'wc' seems to add
On Mon, Apr 21, 2008 at 9:27 AM, Almer S. Tigelaar [EMAIL PROTECTED] wrote:
Hello,
I have been using the 'wc' program (version 5.97) to manually verify
some counts outputted by a component part of an application I am
developing.
I noticed that:
echo 12345 | wc -m
Gives me '6'
Hi,
On Mon, Apr 21, 2008 at 04:27:35PM +0200, Almer S. Tigelaar wrote:
I have been using the 'wc' program (version 5.97) to manually verify
some counts outputted by a component part of an application I am
developing.
I noticed that:
echo 12345 | wc -m
Gives me '6' as output. But I
Didi [EMAIL PROTECTED] wrote:
If by unknown you mean nameless, that's not what the patch does.
Such a patch would not even have been considered.
I agree that hiding this information in some cases might not be
optimal, but the main problem is that through this the 'groups'
command becomes
On Apr 21, 2008, at 4:23 , Didi wrote:
If by unknown you mean nameless, that's not what the patch does.
Such a patch would not even have been considered.
I agree that hiding this information in some cases might not be
optimal, but the main problem is that through this the 'groups'
command
FYI, I've just pushed a big change to the test infrastructure.
It eliminates most of the test/*/Makefile.am files and also solves
Bruno's problem where tests fail if . is too early in PATH.
coreutils snapshot:
http://meyering.net/cu/coreutils-ss.tar.gz8.7 MB
Jim Meyering wrote:
I'm open to all reasonable solutions, especially when accompanied
with sample code.
This is the proposed sample code: the 'expand' program. Here the core
of the program is in the single function expand(). The proposed solution is
like this. It uses a set of macros, which -
18 matches
Mail list logo
