Re: read -t

[Chet Ramey]

On 1/4/15 11:43 AM, isabella parakiss wrote:
> Ok, that makes sense, but why doesn't it work if I change the delimiter?
> 
> read -t 3 -d q       *press random keys without pressing q*
> 
> I think the same should happen here, I'm asking bash to read as much input as
> it can until it reads a q.  Since I don't press q, whatever I typed should be
> used as typeahead.  But that's not the case, and I don't understand why.

Ah, that's a different question.  The -d option sets the end-of-line
delimiter.

-d$'\n' is a no-op: newline is the default, so there's nothing that needs
to change, and when you're reading from the terminal the terminal driver
can handle it without changes.

There are two ways to handle a non-newline delimiter when reading from the
terminal: change the termios end-of-line character to that delimiter, or
read a character at a time and handle the delimiter checking yourself.
The first is not really portable outside Unix, and doesn't offer the
possibility of handling multibyte characters as delimiters.  Bash uses the
second, and it reads a character at a time whether it's reading from the
terminal or not.

When you read a character at a time from the terminal, read(2) returns the
characters and they're not left in the input buffer.  When you don't, and
you leave newline as the end of line character, read(2) doesn't.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/