split

What it does

split breaks a single file into a series of smaller output files, either by a fixed number of lines (-l) or a fixed byte size (-b), without altering the content itself. Output files are named with a prefix (default x) followed by a suffix, alphabetic by default (xaa, xab, xac, ...) or numeric with -d. It's the standard tool for breaking up large logs or files that exceed a transfer or storage size limit.

Beginner examples

• split file.txt — split into 1000-line chunks named xaa, xab, ...
• split -l 500 file.txt — split into 500-line chunks
• split -b 10M bigfile.iso — split into 10MB chunks
• split -l 200 access.log part_ — split with a custom filename prefix

split -l 100000 huge_export.csv chunk_

Advanced examples

• Split a large archive into fixed-size pieces for upload to a size-limited service: split -b 25M backup.tar.gz backup_part_
• Use numeric instead of alphabetic suffixes for easier scripting: split -d -a 3 -l 10000 data.csv part_
• Split into a specific number of roughly equal pieces (GNU split): split -n 4 dataset.csv part_
• Reassemble pieces in the correct order: cat part_* > dataset_restored.csv
• Split while adding a matching file extension to each piece (GNU split): split -b 5M --additional-suffix=.part video.mp4 chunk_

split -d -b 50M dump.sql sqlpart_ && ls sqlpart_*

Common mistakes

• Assuming split compresses or otherwise transforms the data — it doesn't; it purely divides bytes or lines, so total size stays the same (plus tiny per-file overhead).
• Losing track of piece order when using a glob to reassemble (cat part_*) if the default alphabetic suffixes run past z — always verify with -d and zero-padded numbers for anything beyond 26 pieces, or increase -a.
• Splitting a CSV or log file by raw byte count (-b) and cutting a line in half midway through a piece — use -l when line integrity matters.
• Forgetting to specify a prefix, leaving pieces named xaa, xab, etc., which can be confusing when multiple split jobs run in the same directory.

Tips

• Use -d with an explicit -a (suffix length) so pieces sort correctly and predictably once you get past 26 or 676 files.
• Preview how many pieces you'll get before running the real split: wc -l file.txt divided by your -l value gives an estimate.
• For binary files (backups, ISOs, media), always use -b, not -l, since line-based splitting only makes sense for text.

Best practices

• Always verify reassembly with a checksum: sha256sum original.file before splitting and cat part_* | sha256sum after, to confirm no bytes were lost or reordered.
• Choose a descriptive prefix and, on GNU split, -d/--additional-suffix so piece filenames are self-explanatory instead of the cryptic default xaa/xab.
• Prefer -l for text files you might need to inspect or grep piece-by-piece, and -b for anything that will only ever be reassembled whole.

Real-world use cases

• Breaking a multi-gigabyte database dump into upload-friendly chunks: split -b 100M dump.sql dump_part_.
• Splitting a huge CSV export for parallel processing across multiple worker scripts: split -l 50000 export.csv worker_input_.
• Chunking a large log file to email a support team when direct upload isn't possible: split -b 10M -d incident.log log_part_.

Common interview questions

• What's the difference between -l and -b in split? -l splits by a fixed number of lines, keeping line boundaries intact; -b splits by raw byte size, which can cut a line in the middle.
• How do you reassemble files created by split? Concatenate the pieces in order: cat xaa xab xac > original (or cat prefix* > original if the naming sorts correctly).
• Why might you use -d instead of the default suffixes? -d produces numeric suffixes (00, 01, 02...) which sort predictably and scale past 26 pieces, unlike the default alphabetic suffixes which wrap awkwardly.