Re: [PATCH] Use memmove instead of strcpy
On 7/7/18 1:25 AM, Bernhard M. Wiedemann wrote: > In https://bugzilla.opensuse.org/show_bug.cgi?id=1100488 > we found that depending on the build machine, bash-4.4's bash.html would > contain the string Bahh instead of Bash > > strcpy can cause corruption when working on overlapping strings > so we use memmove instead that handles this case correctly Thanks for the report. -- ``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: [PATCH] Fix null environ crash in getenv() provided by lib/sh/getenv.c
On 7/8/18 7:21 AM, Keeley Hoek wrote: > In running bash on an embedded target, bash crashes for the silly > reason that environ is NULL. > > I haven't been able to tell whether this is actually permitted by the > standard (as if?), but in bash I think this behavior is inconsistent > anyway because: It's probably permitted by the standard simply because the standard doesn't specify the value of environ. As a practical matter, on Unix systems, even when execve() is supplied a NULL third argument, environ is never null. It's not unreasonable to check for it, though. 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/
Number with sign is read as octal despite a leading 10#
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 uname output: Linux IO 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.4 Patch Level: 12 Release Status: release Description: A value inside an arithmetic expansion is processed as octal despite using a 10# preffix. Repeat-By: $ echo $((10#+0034)) 28 Fix: Extract optional sign before parsing the number, re-attach after. -- Cases are always threesome: Best case, Worst case, and Just in case
Re: Number with sign is read as octal despite a leading 10#
The + is a unary operator, not part of the literal. Write $((+10#0034)) instead. -- Clint On Jul 9, 2018, 9:24 PM -0400, Isaac Marcos , 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 > uname output: Linux IO 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 > (2018-05-07) x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 4.4 > Patch Level: 12 > Release Status: release > > Description: > A value inside an arithmetic expansion is processed as octal despite using > a 10# preffix. > > Repeat-By: > $ echo $((10#+0034)) > 28 > > Fix: > Extract optional sign before parsing the number, re-attach after. > > -- > Cases are always threesome: > Best case, Worst case, and Just in case
Word boundary anchors \< and \> not parsed correctly on the right side of =~
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 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-vEMnMR/bash-4.4.18=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux monk 4.15.0-24-generic #26-Ubuntu SMP Wed Jun 13 08:44:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.4 Patch Level: 19 Release Status: release Description: Word boundary anchors \< and \> are not parsed correctly on the right side of a =~ regex match expression. This evaluates as false: [[ 'foo bar' =~ \ ]] >From the bash reference manual: An additional binary operator, â=~â, is available, with the same precedence as â==â and â!=â. When it is used, the string to the right of the operator is consid- ered an extended regular expression and matched accordingly (as in regex 3)). Reading regex(3), I presumed the regexes would be parsed as C strings, so the backslashes would need to be escaped: [[ 'foo bar' =~ \\ ]] but this results in: bash: syntax error in conditional expression: unexpected token `<' bash: syntax error near `\\ ]] but this evaluates as true: re='\' [[ 'foo bar' =~ $re ]] and this results in a syntax error: [[ 'foo bar' =~ \\ ]] whereas this is parsed and evaluated correctly: [[ 'foo bar' =~ \\bfoo\\b ]]
