2011-10-3, 08:36(-04), Greg Wooledge: > On Thu, Aug 18, 2011 at 11:10:17AM +0100, Stephane CHAZELAS wrote: >> >> Please read BashFAQ/006: http://mywiki.wooledge.org/BashFAQ/006 >> > "no force in the universe can put NUL bytes into shell strings usefully" > >> No, zsh supports NUL bytes in its strings happily. It's even in >> the default $IFS. Where NUL bytes can't go, it's in arguments >> to commmands, environment variables, filenames... But I can't >> see why a shell variable couldn't contain NUL bytes, it's even a >> good thing for both those reasons as you can use that character >> to safely separate filenames, arguments, env vars... See for >> instance the -0 option of many GNU utilities. > > zsh doesn't count, because it's not compatible with any other shell.
If zsh is not compatible with any other shell, then bash isn't either. What do you mean? > Since this is a bash mailing list (or newsgroup), we're concerned with > the behavior of bash, and bash can't store NUL bytes in strings. The > reason for this is simple enough -- bash uses native C strings for > its variables. [...] I was replying to the "no force in the universe can put NUL bytes into shell strings usefully" statement, pointout out that at least one shell did (and is still POSIX compliant in doing so) and it was very useful. bash code is not fixed in stone, it could be changed to allow NUL bytes. It could even reuse zsh code since zsh is provided under BSD-style license. -- Stephane
