If the input cannot be split into the number of files resulting from the
default suffix length, automatically extend the suffix length rather than
bailing out with 'too many files'.
Suffixes are extended such that the resulting files continue to sort
lexically and "cat *" would reproduce the input. For example, splitting
a 1M lines file into (default) 1000 lines per file would yield files
named 'xaa', 'xab', ..., 'xyy', 'xyz', 'xzaaa', 'xzaab', ..., 'xzanl'.
If '-a' is specified, the suffix length is not auto-extended.
This behavior matches GNU sort(1) since around version 8.16.
file into chunk_count smaller files. Each file will be size/chunk_count
bytes large, with whatever spillover there is ending up in the chunk_counth
file.
a base name wasn't specified. It's not really necessary now that we've
got -a, it's ugly, and POSIX doesn't permit it.
Suggested on tech-userlevel a couple of weeks ago to a deafening silence.
stdout onto each file in turn, then writing through fileno(stdout), use
open() and close() like any sensible program. This saves a lot of system
calls, removes a dependency on the particular behaviour of BSD freopen(),
and allows us to detect and report errors from close().
Correct synopsis to show that -l and -b are mutually exclusive.
Put [k|m] in the right typefaces.
Use .Ql for 'k' and 'm' in text.
Refer to the option-argument of -l as <line_length> consistently.
practical consequence of this is that "-" is treated the same as a file name,
and can't have options specified after it. This is consistent with other
utilities and with POSIX.
that throwing around unsigned long long. There are a few LINTED comments
where I'm sure overflow can never occur, and with these lint gives this
a clean bill of health.