bug(csplit): some regexes, leads to a successfull match and valid regexes treated as invalid regexes

[HackingRepo]

Hi, uutils mainteners

to reproduce that, we need first have an a file by example with that content

relunsec@relunsec:~/software/coreutils/target/debug$ cat a
hello
relunsec@relunsec:~/software/coreutils/target/debug$ 

it can be whatever, but just contains the h ascii char and then

we did

relunsec@relunsec:~/software/coreutils/target/debug$ sudo gnucsplit -b '%.d' a '/^^h/'
gnucsplit: ‘/^^h/’: match not found
6
relunsec@relunsec:~/software/coreutils/target/debug$ ls xx*
ls: cannot access 'xx*': No such file or directory
relunsec@relunsec:~/software/coreutils/target/debug$ sudo ./csplit -b '%.d' a '/^^h/'
0
6
relunsec@relunsec:~/software/coreutils/target/debug$ ls xx*
xx0  xx1

the gnu csplit say '/^^h/' no match however, the uu csplit one sees a match

it also with

relunsec@relunsec:~/software/coreutils/target/debug$ sudo ./csplit -b '%.d' a '/^?[a-z]/'
0
6
relunsec@relunsec:~/software/coreutils/target/debug$ sudo gnucsplit -b '%.d' a '/^?[a-z]/'
gnucsplit: ‘/^?[a-z]/’: match not found
6
relunsec@relunsec:~/software/coreutils/target/debug$ 

and valid regexes by uu treated as invalid, there a completly valid in standard

relunsec@relunsec:~/software/coreutils/target/debug$ cat a
[]
relunsec@relunsec:~/software/coreutils/target/debug$ sudo ./csplit -b '%.d' a '/^[[]]/'
csplit: '/^[[]]/': invalid pattern
relunsec@relunsec:~/software/coreutils/target/debug$ sudo gnucsplit -b '%.d' a '/^[[]]/'
0
3
relunsec@relunsec:~/software/coreutils/target/debug$ 

or just with

relunsec@relunsec:~/software/coreutils/target/debug$ sudo ./csplit -b '%.d' a '/^+/'
0
6
relunsec@relunsec:~/software/coreutils/target/debug$ sudo gnucsplit -b '%.d' a '/^+/'
gnucsplit: ‘/^+/’: match not found
6
relunsec@relunsec:~/software/coreutils/target/debug$ 

[arbelonson-source]

Still reproduces on main (3251833), and it is broader than the two patterns in the report — the two symptoms in the title are one cause.

csplit compiles the pattern with regex::Regex::new (patterns.rs:141), so it gets that crate's Perl-flavoured syntax. POSIX csplit takes a basic regular expression, where the metacharacters are the backslash-escaped ones and the bare ones are literals. The two flavours disagree on every construct where they differ, in both directions.

Against a file of hello / ab+c / a?b / x{2} / a|b / (paren):

pattern	GNU	uutils
/^^h/	no match	match
/^?[a-z]/	no match	match
/ab\+c/	no match	match
/h{1,}/	no match	match
/x{2}/	match	no match
/h\{1,\}/	match	no match
/hel\{2\}o/	match	no match

Six of the seven are the same rule read backwards: \+, \{n,m\} are operators to GNU and literals to us; +, {n,m} are literals to GNU and operators to us. /^^h/ is the same thing for the anchor — in a BRE, ^ is an anchor only in the leading position and a literal everywhere else, so /^^h/ asks for a line beginning with a literal ^ followed by h.

The table understates it slightly: /a|b/ and /(paren)/ are recorded as matching in both, but only because that input happens to contain those characters literally — GNU matches them as literals, we match them as alternation and a group.

Precedent in tree

expr has the same requirement and solved it: check_posix_regex_errors plus a transpile from BRE to onig's Syntax::grep (syntax_tree.rs:243-280). Pointing csplit at the same machinery would fix all seven rows at once, but it swaps out the engine for every csplit pattern, which is not a change to make unannounced — so, is that the direction the maintainers want, or would you rather keep regex and translate the BRE constructs into it?

Separate, while I was here

The pattern in the message is quoted in shell syntax where GNU uses plain quoting, so a backslash or a quote in the pattern comes out differently:

$ csplit -s a '/\./'        # GNU: csplit: '/\\./': match not found
csplit: '/\./': match not found
$ csplit -s a "/a'b/"       # GNU: csplit: '/a\'b/': match not found
csplit: "/a'b/": match not found

Same shape as #13868, which #14294 fixes for dd. Say the word and I will do csplit the same way — it is a one-liner next to the Quotable import.

---

Investigated with AI assistance (Claude Opus 5, via Claude Code); GNU's behaviour was established by running the installed GNU 9.11 binary as a black box.