`csplit` should always suppress lines based on line numbers

[tertsdiepraam]

csplit has multiple ways to split files: based on regex, line numbers and more. The examples in this issue use this file:

seq 1 50 > 50.txt

If we use multiple line numbers in the wrong order, we get an error (both in uutils and GNU):

> csplit 50.txt 20 10
csplit: line number '10' is smaller than preceding line number, 20

So far so good. But, if we use a regex first and then a line number that is smaller than the number of the line where the regex matched we get in trouble:

# GNU
> csplit 50.txt /10/ 5 --suppress-matched
18
0
117

# uutils
csplit 50.txt /10/ 5 --suppress-matched`
18
0
120

The reason is that we seem to make a distinction between the less than and the equal case to determine whether the line should bee suppressed, but GNU doesn't.

cc @BenWiederhake

Found in #6114

[BenWiederhake]

I don't understand this part of csplit, but this explanation also doesn't make sense to me. Specifically because of this interaction:

$ csplit 50.txt 9 '{3}'
16
26
27
27
45
$ head -n1 xx0*; tail -n1 xx0*
==> xx00 <==
1
==> xx01 <==
9
==> xx02 <==
18
==> xx03 <==
27
==> xx04 <==
36
$ csplit --help
[…]
Each PATTERN may be:
  INTEGER            copy up to but not including specified line number
[…]
  {INTEGER}          repeat the previous pattern specified number of times
[…]

Going by the help text, 9 '{3}' should apply the pattern 9 three times. So this should behave the same as csplit 50.txt 9 9 9 9, which it clearly doesn't.

Clearly there is something going on, but the help text of neither GNU nor uutils explain it.

[tertsdiepraam]

Interesting! I think that's another issue though. Looks like GNU interprets 9 {3} as 9 18 27.