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:
>> >> > > ha
> 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 qu
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
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
Solaris 10 SPARC
uname -a
SunOS sparky 5.10 Generic_127111-11 sun4u sparc SUNW,UltraAX-i2
cc -v
cc: Sun C 5.8 Patch 121015-06 2007/10/03
Looks like there isn't an equivalent to a Linux 'mount --bind' on
Solaris?
SKIP: deep-2.log
PASS: deep-1.log
SKIP: hash.log
PASS: dangling-symlink.log
PASS: v-
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 fo
"Allen Hewes" <[EMAIL PROTECTED]> wrote:
> Solaris 10 SPARC
> uname -a
> SunOS sparky 5.10 Generic_127111-11 sun4u sparc SUNW,UltraAX-i2
>
> cc -v
> cc: Sun C 5.8 Patch 121015-06 2007/10/03
>
> Looks like there isn't an equivalent to a Linux 'mount --bind' on
> Solaris?
>
...
> FAIL: one-file-syste
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 c
"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 l
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 t
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
>
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.
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'
> comman
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
http://meyering.net/cu/co
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
