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.
