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 -
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
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
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.
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
>
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
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
"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
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
"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
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
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
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
> 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
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
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
18 matches
Mail list logo
