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
> # 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
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:
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
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 ;;
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
*) echo ;;
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.
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.