Re: Antw: Re: "set -u" and empty arrays
On 5/14/19 2:53 AM, Ulrich Windl wrote:
Chet Ramey schrieb am 13.05.2019 um 21:44 in
Nachricht
> :
>> On 5/9/19 7:07 AM, Ulrich Windl wrote:
>>> Bash Version: 4.3
>>> Patch Level: 48
>>> Release Status: release
>>>
>>> Hi!
>>>
>>> Is this intended with "set -u":
>>> # set -u
>>> # declare -a INSTANCES
>>> # echo ${INSTANCES[*]}
>>> bash: INSTANCES[*]: unbound variable
>>> # INSTANCES=()
>>> # echo ${INSTANCES[*]}
>>> bash: INSTANCES[*]: unbound variable
>>> # echo ${INSTANCES[@]}
>>> bash: INSTANCES[@]: unbound variable
>>
>> This was changed late in the bash-4.4 development cycle (July, 2016). From
>> bash-4.4/CHANGES:
>>
>> a. Using ${a[@]} or ${a[*]} with an array without any assigned elements
>> when
>> the nounset option is enabled no longer throws an unbound variable
>> error.
>
> Thanks for the info! Actually it seems "${#a[*]}" is also affected:
> v04:~> declare -a a
> v04:~> echo ${#a[@]}
> 0
> v04:~> set -u
> v04:~> echo ${#a[@]}
> bash: a: unbound variable
> v04:~> a=()
> v04:~> echo ${#a[@]}
> 0
> v04:~> echo $BASH_VERSION
> 4.3.48(1)-release
That's not an array, though, so its behavior there is expected -- and in
fact, I get the same results in bash 5.0.7(1)-release
When "a" is an unbound array declared with declare -a, its non-array
"how long am I" variable doesn't have an integer inside it, not even
"0". When "a" is a bound array declared with =(), it has a defined
length of 0. So the non-array variable "${#a[@]}"=0, and bash is happy
and continues on with life and doesn't fatally terminate in the middle
of your script in an unexpected fashion.
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: Valgrind detects invalid read in bash. malloc assertion fails.
On 5/14/19 2:16 AM, Grisha Levit wrote: > Reproduces for me on Debian 9 with a fresh bash devel build (with or > without DEBUG and MALLOC DEBUG). Anything with a glob will do to reproduce: > > $ valgrind ./bash -c ': *' chet@caleb-debian9:~$ ./build/bash-5.0.7/bash -c ': *' chet@caleb-debian9:~$ echo $? 0 chet@caleb-debian9:~$ cat /etc/debian_version 9.9 chet@caleb-debian9:~$ ulimit -c unlimited chet@caleb-debian9:~$ ./build/bash-5.0.7/bash -c ': *' chet@caleb-debian9:~$ echo $? 0 chet@caleb-debian9:~$ ./build/bash-5.0.7/bash -c 'echo $BASH_VERSION' 5.0.7(1)-release chet@caleb-debian9:~$ If bash were freeing unallocated memory, the bash malloc would catch it. I assume this is a valgrind false positive. -- ``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: Use high bits of the raw random number?
On 5/9/19 10:29 AM, Peng Yu wrote: > Hi, > > Bash uses the low 16 bits for $RANDOM. > > https://git.savannah.gnu.org/cgit/bash.git/tree/variables.c#n1321 > https://git.savannah.gnu.org/cgit/bash.git/tree/variables.c#n1356 > > It seems that the high bits should be more random. If so, maybe the > high 16 bits should be kept if $RANDOM must stay in 16bits? This seems like something you could test and verify. Change the random number generator in variables.c:brand() to return the high 16 bits ((rseed >> 16) & 32767) and compare the behavior against the existing version over 32768 $RANDOM generations. If you wanted to try a third alternative, you could XOR the high 16 bits with the low 16 and return that. -- ``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: Regression in --enable-minimal-config
On 5/13/19 4:18 AM, Miro Kropáček wrote: > On Sun, 12 May 2019 at 21:32, Martijn Dekker wrote: >> Chet only commits snapshots to git and not individual fixes, so it's >> hard to isolate any one fix from the git repo. > Yes, I have noticed. :-) There is no guarantee that a single commit fixes the issue you want to have fixed, especially if it's not a problem that was identified the same way. In this case, the commit Martijn references definitely fixes a problem with `()' subshells initializing, but it is not identical to the problem with the grep configure script (which fails running shell functions in pipelines, which are run in subshells). That's similar to the report Martijn cited, but not the same. The right one is http://lists.gnu.org/archive/html/bug-bash/2016-11/msg00031.html and the right commit is http://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=78a3f8a4bae8ef98daa26b64ddbc03c6fc3ffcd0 If you look at the changes in that commit, you see +execute_cmd.c + - execute_subshell_builtin_or_function: call without_job_control even + if JOB_CONTROL is not defined. Similar to fix from 9/23. + Report from Martijn Dekker and you should be able to find the right chunk from execute_cmd.c that mentions without_job_control(). 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/
Option '-c' has bug when compile-time config 'ONESHOT' is enabled
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-Wno-parentheses -Wno-format-security
uname output: Linux yudev144 5.0.11-300.fc30.x86_64 #1 SMP Thu May 2
14:11:38 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 5.0
Patch Level: 2
Release Status: release
Description:
This bug was found in bash 4.4.12 (GNU bash, version
4.4.12(1)-release (x86_64-pc-linux-gnu))
It is still here in bash 5.0.2.
I pubilshed it first in this page,
https://unix.stackexchange.com/questions/406674/bash-why-is-alias-after-newline-ignored-when-run-remotely#407064
This is a bug of option '-c'.
It can be reproduced with the command below,
bash -c "shopt -s expand_aliases &>/dev/null;
alias myalias='echo foo
echo bar
echo baz'
myalias
I expect it to output such three lines as follows,
foo
bar
baz
But only 'foo' will be output.
To get the right/expected output, at least one more line has to be added
after 'myalias', like below,
bash -c "shopt -s expand_aliases &>/dev/null;
alias myalias='echo foo
echo bar
echo baz'
myalias
:"
After read the code, I found a solution to fix it without changing any
code, that is to compile bash with 'ONESHOT' undefined.
Whether define 'ONESHOT' or not leads to two completely different route in
Bash code for '-c "command"'. If undefine 'ONESHOT', '-c "command"' will
run the normal code route, which is the code route for almost all bash
executions, such as interactive command and bash script. But if define
'ONESHOT', '-c "command"' will run another particular route which is
specially designed for '-c' only, to improve its performance by avoiding
fork.
The bug is right in the particular route.
Some details about this bug
The following piece of code is where the bug is. It is from function
parse_and_execute() in file builtins/evalstring.c, which is the one enabled
by 'ONESHOT'.
while (*(bash_input.location.string))
{
...
}
This while loop will run by lines, handling one line in one loop. After
read 'myalias', the last line in the problematic command (see above), the
condition in while will become false. 'myalias' is expanded to three lines
of echo, but only one echo is handled in this loop; the two other echos are
intended to be handled in next loops, but... there is no more loops.
If you add one more line after 'myalias', after read 'myalias', the
condition in while will remain true, so the two other echos will get chance
to run in next loops. The last line after 'myalias' will be handled after
all echos expanded from 'myalias' are handled.
