It's a limitation. bash
does not allow string values to contain interior NUL bytes.
Posix (and C) character strings cannot contain interior NULs. See, for example, the Posix definition of character string (emphasis added):
3.92 Character String
A contiguous sequence of characters terminated by and including the first null byte.
Similarly, standard C is reasonably explicit about the NUL character in character strings:
§5.2.1p2 …A byte with all bits set to 0, called the null character, shall exist in the basic execution character set; it is used to terminate a character string.
Posix explicitly forbids the use of NUL (and /
) in filenames (XBD 3.170) or in environment variables (XBD 8.1 "... are considered to end with a null byte."
In this context, shell command languages, including bash, tend to use the same definition of a character string, as a sequence of non-NUL characters terminated by a single NUL.
You can pass NULs freely through bash pipes, of course, and nothing stops you from assigning a shell variable to the output of a program which outputs a NUL byte. However, the consequences are "unspecified" according to Posix (XSH 2.6.3 "If the output contains any null bytes, the behavior is unspecified."). In bash, the NULs are removed, unless you insert a NUL into a string using bash's C-escape syntax ($'\0'
), in which case the NUL will end up terminating the value.
On a practical note, consider the difference between the two following ways of attempting to insert a NUL into the stdin
of a utility:
$ # Prefer printf to echo -n
$ printf $'foo\0bar' | wc -c
3
$ printf 'foo\0bar' | wc -c
7
$ # Bash extension which is better for strings which might contain %
$ printf %b 'foo\0bar' | wc -c
7