<> redirection has changed

[David Terlinden]

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DSHELL -DHAVE_CONFIG_H  -D_FILE_OFFSET_BITS=64  -I.  -I. 
-I./include -I./lib -I/usr/local/include -g -O2
uname output: Linux mux2.webpusher.com 2.2.19 #6 Fri Feb 22 11:26:01 PST 2002 
i686 unknown
Machine Type: i686-pc-linux-gnu

Bash Version: 2.04
Patch Level: 0
Release Status: release

Description:
The behaviour of "<>" redirection has changed somewhere between
bash versions 1.14.7 and 2.04.  The older "bash" implemented "<>" by opening
the file in question twice, once readonly and once writeonly, and then doing
"dup2()" twice, once on fd 0 and once on fd 1.  The newer bash opens the
file in question just once (for read and write) and then does "dup2" just
once for fd 0.  The second way matches the man page description, but it
does not work for at least some practical applications.


Repeat-By:
I ran a serial cable between the comm ports of two linux machines.  On one I did
"tr a-z A-Z <> /tmp/ttyS0", where "/tmp/ttyS0" is identical to "/dev/ttyS0"
except for ownership and permissions.  One the other machine I did
"cu -l /dev/ttyS0 dir".  Then I could type and see capitalized echoing,
thereby verifying that the comm ports worked on both machines.  I can't
use "<>" in this fashion with the newer "bash" and must explicitly redirect
twice, once with ">" and once with "<".

Fix:

Go back to the old way (see "Description:"), but change the man page to indicate
that "<> fff" redirects 0 from fff and 1 to fff, not 0 for both.