# 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 does
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 ty
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
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
>
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
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 l
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.
--
