"Oshea, Richard" <[EMAIL PROTECTED]> writes:
> log>locale
> LANG=en_US.UTF-8
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
That's most likely the problem, then. Your systems are consistent
with sorting with the en_US.UTF-8 locale.
> - Remember, I had set the LC_ALL=C and it did not change
>
> Just so you know - I found a way around the problem.
> I made the primary part of the sort (first field) the same length - and the
> sort
> works correctly.
You still haven't listed the command line invocation that succeeded,
contrasted with the command line that sorted in a manner other
th
Bob,
Whitespace are spaces - checked that out first.
Just so you know - I found a way around the problem.
I made the primary part of the sort (first field) the same length - and the
sort works correctly.
I suspect somewhere in the code, the first whitespace found sets the length for
all elemen
Olivier Delhomme <[EMAIL PROTECTED]> writes:
> So if this flag is linux specific does it mean that dd iflag=directory
> won't run on other unices ?
Yes, that's right. It's just like "dd iflag=noatime". The general
rule is that dd issues a runtime diagnostic and immediately fails if
you try to u
Update of patch #4978 (project coreutils):
Assigned to:None => eggert
___
Follow-up Comment #1:
Alas, this is an incompatible change; look for how 'x' is
treated in the very next line of s
If this is merely for debugging, can't you write a wrapper that forces
line buffering for a program? The wrapper could substitute your own C
library functions via LD_PRELOAD, or could run the program inside a
pseudotty a la 'expect'.
If it's for production use then I'm not sure it's a good idea t
You sent your message to bug-textutils which may indicate that you
have a very old version. The current programs are in the coreutils
package and would have directed you to the bug-coreutils mailing
list. The current stable version is 5.94. But that won't change
anything for the purposes of your
And of course now I read Jim's note with the subject "Remove Utility-
need guidance" which addresses the "Circular directory structure"
problem. Just ignore my message. Sorry for the noise.
Bob
Bob Proulx wrote:
> There was a long delay because the mailing list was offline for
> several days.
Hugh Sasse wrote:
> I've tried to subscribe using bug-coreutils-request but I get
> no response, so I'm sending this in the hope that it will reach
> a useful destination nonetheless.
Thank you very much for making your report. The machine hosting the
mailing list had hardware problems. This cas
There was a long delay because the mailing list was offline for
several days.
Vineet Chadha wrote:
> Modern operating system put the in-core inode into free list and
> sometimes re-allocates inode immediately to NEXT creation of file
> system object.
That may be true. But it has nothing to do wi
Hugh Sasse <[EMAIL PROTECTED]> wrote:
...
>> Would you please run this (from the top level):
>>
>> make && env LC_ALL=C make -C tests/dd check TESTS=skip-seek
>>
>> If that succeeds, then we'll know that the problem is locale-related,
>> making dd's use of ngettext malfunction.
Did you try the a
On Wed, 22 Mar 2006, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Hugh Sasse on 3/22/2006 2:50 AM:
> >
> > Anything else I can tell you?
>
> Try running 'make -C tests/dd TESTS=skip-seek DEBUG=yes VERBOSE=yes check'
> so we can see exactly what the testsu
Hugh Sasse <[EMAIL PROTECTED]> wrote:
...
>> > *** block-sync-1.E Thu Mar 9 18:50:30 2006
>> > --- block-sync-1.3 Thu Mar 9 18:50:30 2006
>> > ***
>> > *** 1,3
>> > 2+1 records in
>> > 0+1 records out
>> > ! 1 truncated records
>> > --- 1,3
>> > 2+1 records i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Hugh Sasse on 3/22/2006 2:50 AM:
>
>> That difference implies your test is running
>> the wrong dd binary. That could be because
>> the PATH setting (original is in Makefile.am in that directory)
>> is not being honored by your make prog
On Wed, 22 Mar 2006, Jim Meyering wrote:
> Hugh Sasse <[EMAIL PROTECTED]> wrote:
> > I've tried to subscribe using bug-coreutils-request but I get
>
> The list software's database was corrupted for a long time, but
> everything seems to be working now.
>
> > no response, so I'm sending this in t
Pádraig Brady <[EMAIL PROTECTED]> writes:
> It's just that above call seems to have no affect,
The standard does not require that setvbuf has any visible effect apart
from honoring the buffering mode.
7.19.5.6 The setvbuf function
... If buf is not a null pointer, the array it points to
Andreas Schwab wrote:
>Pádraig Brady <[EMAIL PROTECTED]> writes:
>
>
>
>>p. p.s. Note glibc changes the buffering automatically for stdout only like:
>>if (isatty(fileno(stdout)) setlinebuf(stdout)
>>Also it always leaves stdin buffered and stdout unbuffered.
>>
>>
>
17 matches
Mail list logo
