Re: non working code .. loop ends after one

[Greg Wooledge]

On Thu, Mar 02, 2023 at 12:07:55AM +0100, alex xmb ratchev wrote:
> i tried make \0 or \n ( or other accessable )
> the bash read -d way is '' for 0 and <real n> for n
> 
> bash read -d sep 'one_char( or more i dunno )'
> in awk it doesnt matter

I'm not 100% sure what you're saying, so I'll just make this clear:

read's -d option only allows a one-character option argument.  That
character will be used as the LINE delimiter, which tells read when
to stop reading.

If the option argument is the empty string (-d '' or -d ""), then
the NUL byte is used as the line delimiter.

This is most likely a side effect of bash's internal code just doing
something like 'delimiter = argument[0];' which happens to retrieve
a NUL byte when argument is an empty string, due to how C strings are
stored internally.

Regardless of whether this was an accident originally, Chet has blessed
it, and it's officially a supported feature now.

To demonstrate, here is a loop that reads a NUL-delimited list of
pathnames from find:

while IFS= read -r -d '' pathname; do
    ...
done < <(find . -type f -print0)

Each read command terminates when it reads a NUL byte, and all of the
bytes read before that go into the "pathname" variable, with no mangling
(because of the -r option, and because IFS is empty).

There is no need to use \0 anywhere in this part of the code.  (Unless
you're using a POSIX find command which lacks -print0, in which case
you might use -exec printf '%s\0' {} + as a workaround.)