Re: document that read built-in can't return zero-length string in the middle of input

[Greg Wooledge]

On Fri, Jan 12, 2024 at 03:26:31PM +0700, Robert Elz wrote:
>     Date:        Thu, 11 Jan 2024 20:02:04 -0500
>     From:        Greg Wooledge <greg@wooledge.org>
>     Message-ID:  <ZaCPjAscvwrwurcJ@wooledge.org>
> 
>   | What actually counts is how many
>   | characters are *stored* in the variable, not how many characters are
>   | *read* from the input.
> 
> I suspect that is the root of the issue here, you're considering
> the word "read" to mean read(2) whereas as it is in the documentation
> for the read command, I suspect it means that one, how many characters
> the read command obtains, rather than how many the read system call
> processes (like elided newlines. when -r is not used, would also not
> be counted, or expected to be, right?)

This was one of the things I tested:


unicorn:~$ { read -N1; read -r b c; } < <(printf \\nabc); declare -p REPLY a b 
cdeclare -- REPLY=$'\n'
declare -- a=$'\n'
declare -- b="abc"
declare -- c=""


(The value of 'a' was from a previous test.)  read -N1 consumed two
characters of the input, and stored one character in the variable.
As a script writer, those are the things I care about.  I don't know
or care about the internals of the shell.

Also note that I'm assuming the implementation isn't going to change,
and that our sole goal in this thread is to document its behavior.
Therefore I don't speak about what's "expected" -- merely what is.

I would, however, strongly recommend that script writers who use
read -N *always* include the -r option.