A common way to do things with a couple of files is—and don't hit me for that:
for f in $(ls); do …
Now, to be safe against files with spaces or other strange characters, a naive way would be to do:
find . -type f -print0 | while IFS= read -r -d '' file; …
Here, the -d '' is short for setting the ASCII NUL as in -d $'\0'.
But why is that so? Why are '' and $'\0' the same? Is that due to the C roots of Bash with an empty string always being null-terminated?
The man page of bash reads:
-d delim
The first character of delim is used to terminate the
input line, rather than newline.
Because strings are usually null terminated, the first character of an empty string is the null byte. - Makes sense to me. :)
The source reads:
static unsigned char delim;
[...]
case 'd':
delim = *list_optarg;
break;
For an empty string delim is simply the null byte.
split() it will split between each character. I suspect a "for historical reasons" may be the best explanation we can get.
– donothingsuccessfully
Jan 12 '13 at 08:48
'\0' with 'X\0' should give you 'X\0', if done right. This doesn't have much to do with high-level functions in languages such as JavaScript @don
– slhck
Jan 12 '13 at 09:06
delim = *list_optarg; makes it clear why it's that way.
– slhck
Jan 12 '13 at 09:08
'' and $'\0' the same?", michas gave the proximate explaination of "that's what the code does". I outlined an alternative way of handling the empty string that I saw as equally reasonable and suggested that chosing one or the other was simply a matter of convention or happenstance.
– donothingsuccessfully
Jan 12 '13 at 12:16
There are two deficiencies in bash that compensate each other.
When you write $'\0', that is internally treated identically to the empty string. For example:
$ a=$'\0'; echo ${#a}
0
That's because internally bash stores all strings as C strings, which are null-terminated — a null byte marks the end of the string. Bash silently truncates the string to the first null byte (which is not part of the string!).
# a=$'foo\0bar'; echo "$a"; echo ${#a}
foo
3
When you pass a string as an argument to the -d option of the read builtin, bash only looks at the first byte of the string. But it doesn't actually check that the string is not empty. Internally, an empty string is represented as a 1-element byte array that contains just a null byte. So instead of reading the first byte of the string, bash reads this null byte.
Then, internally, the machinery behind the read builtin works well with null bytes; it keeps reading byte by byte until it finds the delimiter.
Other shells behave differently. For example, ash and ksh ignore null bytes when they read input. With ksh, ksh -d "" reads until a newline. Shells are designed to cope well with text, not with binary data. Zsh is an exception: it uses a string representation that copes with arbitrary bytes, including null bytes; in zsh, $'\0' is a string of length 1 (but read -d '', oddly, behaves like read -d $'\0').
read changed in bash 4.3 so that it now skips null bytes. For example read x< <(printf a\\0a) sets x to aa instead of a.
– Lri
Jun 09 '14 at 02:45
for f in *instead of parsingls. – Jan 12 '13 at 16:01for i in $(ls)is terribly stupid—I'm almost ashamed I used it as a bad example here. – slhck Jan 12 '13 at 16:04find … -execinstead of looping around files, which works for most cases where you'd use such a for loop instead. Here,findtakes care of everything for you. – slhck Jan 12 '13 at 16:06find … -exec sh -c '…' {} ';'. Here, withinsh -cyou can call the file as the argument and even use multiple lines. See Gilles' answer here for more: http://unix.stackexchange.com/a/9500/5893 – slhck Jan 12 '13 at 16:15