Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #14119 > unrolled thread

Re: Variables can’t contain NUL

Started byGreg Wooledge <wooledg@eeg.ccf.org>
First post2018-05-21 08:37 -0400
Last post2018-05-21 08:37 -0400
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Variables can’t contain NUL Greg Wooledge <wooledg@eeg.ccf.org> - 2018-05-21 08:37 -0400

#14119 — Re: Variables can’t contain NUL

FromGreg Wooledge <wooledg@eeg.ccf.org>
Date2018-05-21 08:37 -0400
SubjectRe: Variables can’t contain NUL
Message-ID<mailman.161.1526906272.1292.bug-bash@gnu.org>
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.

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web