Re: RFE: Fix the name collision issues and typing issues with namerefs, improve various issues for function libraries

2017-06-17 Thread Chet Ramey
On 6/14/17 12:04 PM, tetsu...@scope-eye.net wrote: > > This is relevant to my interests! > > So first off, the circular reference problem with "declare -n" > apparently doesn't exist in Korn Shell: If you "typeset -n x=$1", and > $1 is "x", it's not a circular reference. The nameref seems to

Re: Buffer corruption when the terminal is resized.

2017-06-17 Thread Chet Ramey
On 6/12/17 9:49 PM, Paul Peet wrote: > Yes, indeed, rewrapping the contents on resize breaks this assumption. > > Given that in a(n obviously non-representative) poll about 1.5 years > ago at https://opensource.com/life/15/11/top-open-source-terminal-emulators, > terminal emulators that now (not

Re: Issues with `rl_vi_change_char' function in combination with `_rl_vi_redoing = 1'

2017-06-17 Thread Chet Ramey
On 6/17/17 5:27 AM, Eduardo A. Bustamante López wrote: > # When bash is compiled with multibyte support, the following happens: > > - set -o vi > - Type: <ñ><.> > - Bash writes \261 to `mb[0]' and '\0' to `mb[1]' (ñ is U+00F1, or in > UTF-8, \303\261) This needs changes similar to

Issues with `rl_vi_change_char' function in combination with `_rl_vi_redoing = 1'

2017-06-17 Thread Eduardo A . Bustamante López
# When bash is compiled with multibyte support, the following happens: - set -o vi - Type: <ñ><.> - Bash writes \261 to `mb[0]' and '\0' to `mb[1]' (ñ is U+00F1, or in UTF-8, \303\261) - `mb' is of type signed char, and not really suitable to store a wide character. dualbus@debian:~$ set

[PATCH] Bash does not build when --disable-multibyte due to missing HAVE_MULTIBYTE guard in display.c

2017-06-17 Thread Eduardo A . Bustamante López
dualbus@debian:~/src/gnu/bash$ git diff -- lib/readline/display.c diff --git a/lib/readline/display.c b/lib/readline/display.c index d5536211..1f281cd3 100644 --- a/lib/readline/display.c +++ b/lib/readline/display.c @@ -2127,7 +2127,7 @@ dumb_update: cpos_adjusted = 1;

Return code of coproc when NAME is not a legal_identifier

2017-06-17 Thread Eduardo A . Bustamante López
The manual is clear on this: Since the coprocess is created as an asynchronous command, the coproc command always returns success I'd argue that it should return an error code for this particular case though: $ bash -c 'coproc % { :; }; echo $?' bash: `%': not a valid identifier 0