Bugreport builtin command 'read'

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Bugreport builtin command 'read'

skynet@top-email.net
# GNU bash, Version 4.4.12(1)-release
# Builtin command 'read'

while read -p "Select! (y/n): "; do
        case "$REPLY" in
                [yY]) echo "Yes selected!"; break ;;
                [nN]) echo "No selected!"; break ;;
        esac
done

# Bug 1?: +Option read -n1
- Cursor doesn't jump automaticly to next line
# Bug 2: +Options read -n1 -e
- Command freezes in case of typing characters like öäü' and so on. (German
keyboard layout)
Reply | Threaded
Open this post in threaded view
|

Re: Bugreport builtin command 'read'

Greg Wooledge
On Thu, Jan 04, 2018 at 11:24:30AM +0100, [hidden email] wrote:
> # Bug 1?: +Option read -n1
> - Cursor doesn't jump automaticly to next line

It's not supposed to.  If you want that, just do an "echo" after the
read.

> # Bug 2: +Options read -n1 -e
> - Command freezes in case of typing characters like öäü' and so on. (German
> keyboard layout)

Confirmed on Debian 9 with locale en_US.UTF-8.  In an interactive shell,
issuing "read -n1 -e" and then typing í (Compose + ' + i) causes í to be
displayed, followed by a newline; the read command does not terminate.
Sending another character (e.g. space) causes that character to be
displayed, without a newline, but the read still does not terminate.
Pressing Enter finally terminates the read command, and issues TWO
shell prompts.

Repeating again, with "ájkEnter" as input, gives á + newline, jk + newline,
a shell prompt with "k" shown as an entered command, the error message
"bash: k: command not found", and then a second shell prompt.
The REPLY variable contains:

wooledg:~$ printf %s "$REPLY" | od -t x1
0000000 c3 6a
0000002

In other words, it contains the first byte of á (c3) and then the single
byte for j (6a), which I believ is not a valid character string.

Reply | Threaded
Open this post in threaded view
|

Re: Bugreport builtin command 'read'

skynet@top-email.net
Am Donnerstag, 4. Januar 2018, 14:43:02 CET schrieb Greg Wooledge:
> On Thu, Jan 04, 2018 at 11:24:30AM +0100, [hidden email] wrote:
> > # Bug 1?: +Option read -n1
> > - Cursor doesn't jump automaticly to next line
>
> It's not supposed to.  If you want that, just do an "echo" after the
> read.

Okay, I assumed it wasn't a bug. But it's not optimal either.

Without the -n option, the read command is always terminated with a line break, so
the following example works well.

while read -p "Select! (y/n): "; do
        case "$REPLY" in
                [yY]) echo "Yes selected!"; break ;;
                [nN]) echo "No selected!"; break ;;
        esac
done

With the -n option you have to rewrite the whole example as follows to make it work
the same way.

while read -n1 -p "Select! (y/n): "; do
        case "$REPLY" in
                [yY]) echo -e "\nYes selected!"; break ;;
                [nN]) echo -e "\nNo selected!"; break ;;
                '') continue ;; # Here no additional
command 'echo'
                *) echo ;;
        esac
done

Maybe you could change this so that you only change the -n option and not the
whole construct afterwards. I see no reason why the read command should react
differently with this option.
Reply | Threaded
Open this post in threaded view
|

Re: Bugreport builtin command 'read'

Greg Wooledge
On Thu, Jan 04, 2018 at 03:34:40PM +0100, [hidden email] wrote:
> Without the -n option, the read command is always terminated with a line break

Untrue.  Without -s, read simply echoes what the user types.  That
includes that newline (Enter) that normally terminates input (unless
overridden by -d or -n or -N).

E.g.:

wooledg:~$ read -s -p "Password: " password; echo "got it"
Password: got it
wooledg:~$

There's no "line break" after I enter the password, because the -s option
suppresses echoing back my input, which includes the Enter.  If I want
a newline there, it's my job as the script writer to print one.

Reply | Threaded
Open this post in threaded view
|

Re: Bugreport builtin command 'read'

Chet Ramey
In reply to this post by skynet@top-email.net
On 1/4/18 5:24 AM, [hidden email] wrote:

> # Bug 2: +Options read -n1 -e
> - Command freezes in case of typing characters like öäü' and so on. (German
> keyboard layout)

Thanks for the report.  This bug was fixed back in May, 2017 as the
result of a report from Eduardo Bustamante.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [hidden email]    http://tiswww.cwru.edu/~chet/