Mixing process substitution and redirections causes crash
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux [HOSTNAME] 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 15:35:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.3 Patch Level: 42 Release Status: release Description: It seems that mixing process substitution interacting with the terminal and redirections has undesired effects on bash's own sighandlers. Any 'crashing' command with a redirection like: `< <( cat - )` will cause bash to crash. This happens *only* when bash is run directly in the terminal (or tty), when running bash under bash (or under anything else) doesn't seem to allow to replicate the bug. Repeat-By: # THIS IS INTENDED TO CAUSE BASH TO CRASH. Run with care. sleep 10 < <( cat - ) & killall sleep # In general: ./a.out < <( cat - ) # when a.out crashes.
Re: bash prints numeric values of unicode characters instead of their UTF8 representations
On 2/3/16 7:54 PM, Yuri wrote: > On 01/31/2016 13:41, Yuri wrote: >> >> What makes bash print unicode charater ascii values? > > I found what the problem is: > --disable-nls causes HAVE_ICONV being undefined and \u feature not work. AM_GNU_GETTEXT is the autoconf macro that adds the --disable-nls option to configure. It handles checking for iconv by calling AM_ICONV. If you disable it by calling configure with --disable-nls, it doesn't look for iconv. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash can't distinguish between empty and unset arrays
On 2/3/16 6:43 PM, Martijn Dekker wrote:
> bash treats an empty array as if it were an unset variable, which seems
> very illogical as empty is quite distinct from unset:
>
> $ myarray=()
> $ [[ -v myarray ]] && echo set || echo unset
> unset
If you use the name of an array in a variable context without using a
subscript, it's equivalent to referencing element 0.
Bash considers a variable set if it has been assigned a value. For an
array, being set means that the number of elements is greater than zero.
> $ set | grep ^myarray=# yet, it's set:
> myarray=()
Yes, this is arguably a bug. Bash tries to output the set of shell
variables in a way that will restore them if the output is evaluated,
but only puts array variables in the `set' output. It doesn't do that
for variables that have been assigned attributes but not values; such
variables are lost.
> $ set -u
> $ for i in "${x[@]}"; do :; done
> bash: x[@]: unbound variable
None of the elements have been assigned a value.
> Note also that the "unbound variable" error is inconsistent with the
> behaviour of "$@"; I would have thought that, logically, "$@" and
> "${x[@]}" should behave the same way, since arrays are implemented as a
> logical extension of the positional parameters concept.
$@ and $* receive a special carve-out in Posix; they are the only
exceptions to set -u.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash prints numeric values of unicode characters instead of their UTF8 representations
On 2/3/16 4:54 PM, Yuri wrote: > And why the same escape character is interpreted in two different ways > within the same piece of software? Because $'...' is posix (or soon to be) and standardized and PS1 interpretation is historical bash practice. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Mixing process substitution and redirections causes crash
hello, it is no longer existent in the recent devel: GNU bash, version 4.4.0(3)-rc1 (i686-pc-linux-gnu) while it is reproducible in the version you file the report for. sincerely, pg On Fri, Feb 5, 2016 at 10:23 AM, wapiflapi wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib > -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat > -Werror=format-security -Wall > uname output: Linux [HOSTNAME] 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 > 15:35:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 4.3 > Patch Level: 42 > Release Status: release > > Description: > > It seems that mixing process substitution interacting with the terminal > and redirections has undesired effects on bash's own sighandlers. Any > 'crashing' command with a redirection like: `< <( cat - )` will cause > bash to crash. This happens *only* when bash is run directly in the > terminal (or tty), when running bash under bash (or under anything else) > doesn't seem to allow to replicate the bug. > > Repeat-By: > > # THIS IS INTENDED TO CAUSE BASH TO CRASH. Run with care. > sleep 10 < <( cat - ) & killall sleep > > # In general: > ./a.out < <( cat - ) # when a.out crashes. >
Re: bash prints numeric values of unicode characters instead of their UTF8 representations
On 02/05/2016 11:13, Chet Ramey wrote: AM_GNU_GETTEXT is the autoconf macro that adds the --disable-nls option to configure. It handles checking for iconv by calling AM_ICONV. If you disable it by calling configure with --disable-nls, it doesn't look for iconv. Well, this is wrong in the bash context, because bash needs iconv in unrelated to gettext context. Yuri
