behavioral change of "read" builtin for sh on 8-CURRENT

From: Michael Proto <mike_at_jellydonut.org>
Date: Wed, 10 Dec 2008 00:49:58 -0500
I've noticed a behavioral difference of the "read" builtin statement within
/bin/sh on CURRENT and I'm hoping someone can point me in the right
direction on how to restore the old behavior.

I have a /bin/sh script that accepts input for IP address information:

#!/bin/sh
set -x
DEFINT=vr0
DEFIP=192.168.0.1
DEFMASK=255.255.255.0
read -p "Enter network interface [$DEFINT]: " -t 5 INT
read -p "Enter IP address [$DEFIP]: " -t 5 IP
read -p "Enter netmask [$DEFMASK]: " -t 5 MASK
echo ${INT:=$DEFINT} : ${IP:=$DEFIP}/${MASK:=$DEFMASK}


This script waits for terminal input for each of the above variables (INT,
IP, MASK) and defaults to a script-provided value if no input is entered in
5 seconds for each variable. On 6.x and 7.x if I simply hit Enter at the
prompt (and don't provide any input) no value is assigned to the variable so
my INT, IP, and MASK variables are set to null and the parameter
substitution of the DEF* variables works as expected.

On 8-CURRENT if I hit Enter with no input at the prompt the system seems to
recognize the newline as input and continues to sit there until I hit Enter
again. When I do this there appears to be a strange unprintable value
assigned to the INT, IP, and MASK variables yet the variable subsitution
doesn't work correctly.

The man page on sh lists the following behavior for read:

     read [-p prompt] [-t timeout] [-er] variable ...
             The prompt is printed if the -p option is specified and the
stan-
             dard input is a terminal.  Then a line is read from the
standard
             input.  The trailing newline is deleted from the line and the
             line is split as described in the section on White Space
             Splitting (Field Splitting) above, and the pieces are assigned
to
             the variables in order.  If there are more pieces than
variables,
             the remaining pieces (along with the characters in IFS that
sepa-
             rated them) are assigned to the last variable.  If there are
more
             variables than pieces, the remaining variables are assigned the
             null string.


As I interpret this, read should delete the trailing newline and assign a
null value since there is is no "input" before the newline. Then the
variable substitution should take over and assign the DEF* variables
appropriately. 6 and 7 follow this but 8 does not.

Here's the output of the script (with set -x) to help show what I'm seeing.

This is on 6 and 7:

+ DEFINT=vr0
+ DEFIP=192.168.0.1
+ DEFMASK=255.255.255.0
+ read -p Enter network interface [vr0]:  -t 5 INT
Enter network interface [vr0]:
+ read -p Enter IP address [192.168.0.1]:  -t 5 IP
Enter IP address [192.168.0.1]:
+ read -p Enter netmask [255.255.255.0]:  -t 5 MASK
Enter netmask [255.255.255.0]:
+ echo vr0 : 192.168.0.1/255.255.255.0
vr0 : 192.168.0.1/255.255.255.0


And this is what I see with 8:

+ DEFINT=vr0
+ DEFIP=192.168.0.1
+ DEFMASK=255.255.255.0
+ read -p Enter network interface [vr0]:  -t 5 INT
Enter network interface [vr0]:
+ read -p Enter IP address [192.168.0.1]:  -t 5 IP
Enter IP address [192.168.0.1]:
+ read -p Enter netmask [255.255.255.0]:  -t 5 MASK
Enter netmask [255.255.255.0]:
/: cho
/:

Strange that the "echo" statement is missing the first "e" character in the
debug output.

Even stranger on 8-CURRENT, if I *do* enter input before the newline (say I
change the IP address or the network interface), the first character is not
echoed back to the screen but is still saved to the variable. Here's an
example when I run the script and provide input at each prompt:

+ DEFINT=vr0
+ DEFIP=192.168.0.1
+ DEFMASK=255.255.255.0
+ read -p Enter network interface [vr0]:  -t 5 INT
Enter network interface [vr0]: r0
+ read -p Enter IP address [192.168.0.1]:  -t 5 IP
Enter IP address [192.168.0.1]: 92.168.0.1
+ read -p Enter netmask [255.255.255.0]:  -t 5 MASK
Enter netmask [255.255.255.0]: 55.255.255.0
+ echo br0 : 192.168.0.1/255.255.255.0
br0 : 192.168.0.1/255.255.255.0
+ echo ifconfig br0 inet 192.168.0.1 netmask 255.255.255.0

Notice that when I'm prompted, the first character doesn't echo but is still
saved in the variable.


Does anyone else see this same behavior? Any ideas on how to reset it back
to how it works in STABLE? I'm not doing anything special with IFS so I'm
stumped on how to troubleshoot this.



Thanks,
Proto
Received on Wed Dec 10 2008 - 05:11:56 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:38 UTC