csplit: error doesn't exit program

[Devel08]

uutils doesn't output 0, for more info, see coreutils/coreutils#305

How to reproduce

$ mkdir a

gnu

$ csplit a '/^a/'
csplit: read error: Is a directory
0

uutils

$ cargo run csplit a '/^a/'
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.24s
     Running `target/debug/coreutils csplit a '/^a/'`
csplit: read error: Is a directory

[arbelonson-source]

Noting for whoever reviews this: there are now two open PRs against this issue, #13206 and #14295 (mine), and they take different approaches — worth flagging so effort isn't duplicated further.

#13206 catches any error from csplit() at the top level and unconditionally prints 0 before exiting. That overcorrects: MatchNotFound and LineOutOfRange already call finish_split() before returning on main, so they already print the actual accumulated count, which usually isn't 0:

$ csplit f '/^zzz/'      # f has more than 0 matching lines before the miss
6                         # GNU prints this too — the real count, not 0
csplit: '/^zzz/': match not found

Forcing 0 in all cases would make that regress.

#14295 only changes the read-error path — the one case that doesn't already call finish_split() — by routing it through the same close-the-split-first logic the other two errors use, so it inherits the correct count in every case rather than a hardcoded one, and respects --quiet/-z/-k the way the existing paths do.

Happy to fold ideas from #13206 in if there's a case it handles that mine doesn't — from what I can tell it's the exception-handling shape (catch-all after uumain) versus mine (fix it at the point of failure), and I don't see an input where the shapes produce different results other than this regression. Deferring to a maintainer's read.

---

Investigated with AI assistance (Claude Opus 5, via Claude Code).