Thomas Habets <[EMAIL PROTECTED]> writes:
> They may be the same number, but they sure aren't treated as equal
> (sort-order equal) by sort. sort -n gives "3 3.0 3.000" every time
> here, no matter the input order. As does "3 03 3".
That is because ties are broken at the end by a last-resort tex
[EMAIL PROTECTED] (Paul Jarc) writes:
>> Sort of, but not quite.
>
> I couldn't find the "not quite" part of your explanation.
Well, I tried. :-)
>> "sort -rR" should output in the reverse order of "sort -R".
>
> Nit: they shouldn't expect that unless they also specify a seed.
Yes, of course.
I installed this, to fix some errno glitches that I noticed when
writing the other "paste" patches.
2004-09-02 Paul Eggert <[EMAIL PROTECTED]>
Output correct errno-related diagnostic on "paste" I/O errors.
* src/paste.c (write_error, xputchar): New functions.
(paste_para
I installed the following obvious little "paste" patch to improve on
the one I recently circulated.
2004-09-02 Paul Eggert <[EMAIL PROTECTED]>
* src/paste.c (paste_parallel): Use index test instead of NULL,
and NULL instead of a separate boolean array.
Index: paste.c
==
On Thursday 02 September 2004 08:47, you wrote:
> > This means that two different files, that happen to sort to the same
> > output, should give the same output when randomized with the same SEED.
> > Is that right? [*]
> and then sort as if that were the correct order. Part of the idea is
> that
Felix von Leitner <[EMAIL PROTECTED]> writes:
> paste does not compile, because it tries to instantiate two FILE
> variables just for the purpose of having values for FILE* to
> recognize later.
Thanks for reporting this. I agree with Paul Jarc that the proposed
fix wouldn't work in general, so
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Thomas Habets <[EMAIL PROTECTED]> writes:
>
>>> sort: Add an ordering option -R that causes 'sort' to sort according
>>> to a random permutation of the correct sort order.
>>
>> This means that two different files, that happen to sort to the same outpu
