bin/129566: behavioral change of "read" builtin for sh(1) on
8-CURRENT
Jilles Tjoelker
jilles at stack.nl
Fri Mar 6 09:40:04 PST 2009
The following reply was made to PR bin/129566; it has been noted by GNATS.
From: Jilles Tjoelker <jilles at stack.nl>
To: bug-followup at FreeBSD.org
Cc: ed at freebsd.org, yanefbsd at gmail.com
Subject: Re: bin/129566: behavioral change of "read" builtin for sh(1) on
8-CURRENT
Date: Fri, 6 Mar 2009 18:37:10 +0100
I do not have an 8-CURRENT box to test on, but it seems the problem with
read -t is indeed due to the new tty layer.
What the read builtin with -t does, is as follows: set "raw" terminal
mode, select for input, put back terminal modes (all sets with TCSANOW).
The issue is the behaviour when the terminal is switched from
non-canonical to canonical mode while there is data queued. POSIX seems
vague about this. You can see the behaviour without relying on
non-standard options to the read builtin like this:
inf=`stty -g`; stty raw; sleep 2; echo -n :; stty "$inf"; read x; echo "$x"
Something should be typed during the sleep 2.
I can distinguish three behaviours: FreeBSD 7 reprocesses the characters
in the input queue (possibly echoing them, sending signals, terminating
the line, etc, as appropriate), Linux puts the characters in the input
line but does not do any processing (for example, a backspace shows up
as ^H or ^? after a ^R) and Solaris keeps the characters in the input
queue but not in the input line (^R does not show them; however, a
newline is still required for the read to complete).
The new tty layer code seems to behave like Solaris here (only from
reading the code, not experimentation).
Also note that <Return> is ^M, which is normally mapped to newline (^J)
but not under 'stty raw'. So that will not terminate a line if the input
queue is not reprocessed.
The code in sh(1) will only work properly with the FreeBSD 7 behaviour.
A workaround is possible by reading input while in raw mode and putting
it back using TIOCSTI after having enabled ICANON, but this is
necessarily racy and does not fix running 7.x sh(1) on 8.x.
By the way, shells/44bsd-csh also does trickery with canonical mode
(Esc/^D filename completion).
--
Jilles Tjoelker
More information about the freebsd-bugs
mailing list