All kinds of binary data might have a NUL byte. E.g. if you want to write a NUL byte to a file in the shell, you might try something like

    echo -n $'\0' > nul

This doesn't work for the reason stated in the article. The argument is instead interpreted as a string ended at the NUL byte and the file will be empty. BTW you can get around this with printf since it processes escape sequences internally.

    printf '\0' > nul

There's also `echo -ne '\0'`, which works similarly (it tells echo to interpret the escape sequences).

The article does mention one usage, near the end, starting with the text "The “abstract” socket feature..."

Others have mentioned "arbitrary binary data", but a concrete example of that (that I know of, not that would be particularly useful to pass around) is the WASM bytecode format: it starts with '\0ASM', using the NUL byte to signify to tools reading it that it isn't text and they shouldn't attempt to display it (or anything like that). However, it is a _byte_code format, and as such, it would be represented with a `char*` pointer in C. Yet, any APIs that use NUL terminated [byte]strings would stop at the very first byte, and not keep any more data beyond than that.

Maybe not particularly useful but we have an nbdkit plugin that lets you specify disks on the command line. If the disk contains any zero bytes (which is very common for disk images obviously) then you have to use base64 encoding instead of directly encoding them, for example by using $(echo -e). http://libguestfs.org/nbdkit-data-plugin.1.html

File names in UTF-32 encoding?

One common usage: NUL bytes are useful as a separator between file names etc if you want to be prepared for any possible name. E.g. many commandline tools have a "-print0" flag to switch from newlines to NUL-bytes in their output.