For reference, and I don't know if this is the same bug or just related, but here's the original bug I ran into:
-- >8 -- $ rm xx*; seq 999 | csplit - /10/-5 30 /10/-5 {2} %10% 110 8 70 195 3 3 28 3560 $ head -n99999 xx* ==> xx00 <== 1 2 3 4 ==> xx01 <== 5 6 7 8 9 10 ... 29 ==> xx02 <== 30 ... 94 ==> xx03 <== 95 ==> xx04 <== 96 ==> xx05 <== 103 104 105 106 107 108 109 ==> xx06 <== 110 ... 999 -- >8 -- Where'd 100..102 gone? Compare s:%:/:g: -- >8 -- $ rm xx*; seq 999 | csplit - /10/-5 30 /10/-5 {2} /10/ 110 8 70 195 3 3 21 28 3560 $ head -n99999 xx* ==> xx00 <== 1 2 3 4 ==> xx01 <== 5 6 7 8 9 10 ... 29 ==> xx02 <== 30 ... 94 ==> xx03 <== 95 ==> xx04 <== 96 ==> xx05 <== 97 98 99 100 101 102 ==> xx06 <== 103 104 105 106 107 108 109 ==> xx07 <== 110 ... 999 -- >8 -- And compare my diagram: /10/-5 30 /10/-5 {2} %10% 110 expr 0 1 2 rep 1-4 5-29 30-94 95 96 97-99 100-109 110-999 line 00 01 02 03 04 05 06 07 file When the "10" regex is %-wrapped, file 05 is not allocated, as expected. POSIX leaves what happens when applying an expression would leave a zero-sized file unspecified, which is why it's legal for coreutils csplit to always eject a line; for comparison, NetBSD &a. csplit creates 2 empty files for the /10/-5 {2} expression, for obvious reasons. Consider therefore the same diagram but vertical (annotation signifying file start): -- >8 -- 1 xx00 2 3 4 5 xx01 6 7 8 9 10 ... 29 30 xx02 ... 94 95 xx03 96 xx04 97 xx05 98 99 100 xx06 101 102 103 104 105 106 107 108 109 110 xx07 ... 999 -- >8 -- Since in the csplit language, for a constant input, all expressions sans %expr% can be reduced to line number expressions¹, here's the equivalent invocation: -- >8 -- $ rm xx*; seq 999 | csplit - 5 30 95 96 97 %10% 110 8 70 195 3 3 40 3560 $ head -n99999 xx* ==> xx00 <== 1 2 3 4 ==> xx01 <== 5 6 7 8 9 10 ... 29 ==> xx02 <== 30 ... 94 ==> xx03 <== 95 ==> xx04 <== 96 ==> xx05 <== 100 101 102 103 104 105 106 107 108 109 ==> xx06 <== 110 ... 999 -- >8 -- So, again, this appears to be lookbehind rearing its filthy head again. Best, наб ¹ I don't think this is strictly true for the strict POSIX dialect without a forward-progress hatch, like NetBSD, but it is true for the coreutils dialect where a regex expression always ejects a line. Whatever, you get the point.
signature.asc
Description: PGP signature