[patch] size reduction for dos2unix/unix2dos

[Rob Landley]

On Sunday 28 August 2005 14:54, Bernhard Fischer wrote:
> Hi,
>
> [in order to not always add to the size of busybox, let me suggest a
> size reduction this time]

Applied.

I didn't add the new test cases because I'm experimenting with a new test 
harness format which I may switch stuff over to in the next day or two.  
Depends what bugs my sort tests uncover.

Rob

P.S.  Speaking of sort corner cases, how's this one?  Start with:

echo "7 3       42      soup
999     3       0       algebra
42      1       010     zoology
42      1       3       woot
egg     1       2       papyrus
" | sort -k2,3n

Try that with gnu sort or busybox sort and you get the same answer (lines 
3,4,5,1,2 respectively).

Now try feeding the same data into "sort -k2,3nr".  With busybox sort you get 
the exact reverse of the above (21543).  But with gnu sort, that does _not_ 
produce the reverse, it instead produces lines 12543.

Then try "sort -k2,3n -r" on both, and watch them not match again...

Lots of staring at the spec going on.  In the first case, I'm trying to figure 
out if this bit of susv3's sort spec:

> When there are multiple key fields, later keys shall be compared only after
> all earlier keys compare equal. Except when the -u option is specified,
> lines that otherwise compare equal shall be ordered as if none of the
> options -d, -f, -i, -n, or -k were present (but with -r still in effect, if
> it was specified) and with all bytes in the lines significant to the
> comparison. The order in which lines that still compare equal are written is
> unspecified.      

Means that the fallback sort should inherit only a _global_ -r, or if it 
should inherit a -r option applied to the last key.  (When you have multiple 
keys, and some have -r and some don't, what's the right thing to do?)

Buch boggling and going "hmm"...

It would be so much easier writing test harnesses if I didn't keep wandering 
off on tangents due to having found bugs.  (Especially "bugs" that involve 
our implementation and somebody else's implementation differing with the very 
real possibility that neither one is actually correct...)

Rob