Re: unexpected behavior of 'read' builtin

[Dave B]

On Saturday 24 May 2008 02:44, Juliano F. Ravasi wrote:

> Description:
> 
> I got bitten by two unexpected (and undocumented) behaviors of
> the 'read' builtin.
> 
> The first one is that it doesn't seem to handle word separators
> equally, making distinction when spaces and non-space
> separators are used to separate words.

The man page introduces the concept of "IFS whitespace", which seems to include
space and tab characters. 

"If IFS has a value  other than the default, then sequences of the whitespace
characters space and tab are ignored at the beginning and end of the word, as
long as the whitespace character is in the value of IFS (an IFS whitespace
character). Any character in IFS that is not IFS whitespace, along with any
adjacent IFS whitespace characters, delimits a field.  A sequence of IFS
whitespace characters is also treated as a delimiter."

So, if I read that correctly (which might not be true of course), when you
assign $'\t' (an IFS whitespace character) to IFS, it seems you fall into the
case where "a sequence of IFS whitespace characters is also treated as a
delimiter".

> The second one is that it chops leading and trailing whitespace
> when you provide one variable for assignment, and not when you
> use the default $REPLY.

This /seems/ to be documented. From the man page, section about "read":

"If no names are supplied, the line read is assigned to the variable REPLY".

So, I guess "the line read" here really means "the whole line", including
leading/trailing spaces.

On the other hand, when even a single name is supplied, word splitting is
performed, so the removal of blanks is expected as the result of that.

-- 
D.