Re: Variables can’t contain NUL

[Greg Wooledge]

On Sun, May 20, 2018 at 04:56:48AM +0200, Garreau, Alexandre wrote:
> On 2015-11-13 at 07:17, Greg Wooledge wrote:
> > Actually in the most general case, where those output streams may
> > contain NUL bytes, it requires two temp files, because you can't store
> > arbitrary data streams in bash variables at all.
> 
> Why do bash variables use 0-terminated arrays instead of arrays structure
> with a length attribute?

The answer to virtually every bash question that contains the word "why"
is: "Because it has always been done that way."

And if you don't like that answer, the next answer is "Bash is just a
shell, not a real programming language.  If you don't like it, use a
real programming language instead."

If you're looking for some deeper answer, like "Why did Stephen Bourne
write it this way back in 1977?" then I would hazard a guess along the
lines of "It is tightly coupled to the underlying C argument-passing
interface which uses NUL-terminated strings."

The idea of using an internal string representation which differs from
the input and output encodings didn't really catch on until modern
Unicode was invented circa 1992.  Also remember that the computers of
the late 1970s were many orders of magnitude slower than today's, so
adding a translation step every time a string went from internal rep to
output encoding (which would include every time a string was passed as an
argument to a non-builtin command) might have made the shell even slower.
Not to mention the severe memory limitations.