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

Thanks! PR 129566 filed on this issue.



-Proto

On Wed, Dec 10, 2008 at 4:27 PM, Giorgos Keramidas <keramida_at_freebsd.org>wrote:

> Hi Michael,
>
> This looks like a bug in 8.0-CURRENT.
>
> Can you please file a bug report and include the text you sent below?
>
> On Wed, 10 Dec 2008 00:49:58 -0500, "Michael Proto" <mike_at_jellydonut.org>
> wrote:
> > 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
> > _______________________________________________
> > freebsd-questions_at_freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe_at_freebsd.org"
> >
>
> --
>