Bugreport builtin command 'read'
# 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)
Re: Bugreport builtin command 'read'
On Thu, Jan 04, 2018 at 11:24:30AM +0100, sky...@top-email.net 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 000 c3 6a 002 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.
Re: foo=$*: ^A and DEL are prefixed or removed
The latest development snapshot appears to have fixed this bug. However, it introduced a new one: if the positional parameters are empty, then foo=$* produces a segfault. Thanks, - Martijn
Re: Bugreport builtin command 'read'
Am Donnerstag, 4. Januar 2018, 14:43:02 CET schrieb Greg Wooledge: > On Thu, Jan 04, 2018 at 11:24:30AM +0100, sky...@top-email.net 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.
Re: Bugreport builtin command 'read'
On Thu, Jan 04, 2018 at 03:34:40PM +0100, sky...@top-email.net 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.
Re: foo=$*: ^A and DEL are prefixed or removed
On 1/4/18 8:56 AM, Martijn Dekker wrote: > The latest development snapshot appears to have fixed this bug. > > However, it introduced a new one: if the positional parameters are > empty, then > > foo=$* > > produces a segfault. Hmmm...I thought that was part of the test suite. I'll take a look. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bugreport builtin command 'read'
On 1/4/18 5:24 AM, sky...@top-email.net 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, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
