Hi,
I've uncovered a very unusual race condition when using process
substitution and developed as minimal a reproducer as I could create:
set -e
private="$(wg genkey)"
public="$(wg genkey | wg pubkey)"
preshared="$(wg genpsk)"
ip link del wg0 type wireguard || true
ip link add wg0 type wireguard
Thank you. Patch applied and (performance) tested with come tests I was
working on
https://github.com/eludom/snippits/tree/master/bash/tests bottom line:
Before:
...
lines_per_sec 993.37 LINES 270 ELAPSED 2718
lines_per_sec 955.95 LINES 280 ELAPSED 2929
lines_per_sec 921.51 LINES 2
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-2bxm7h/bash-5.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname out
Apr 19, 2020, 21:20 by chet.ra...@case.edu:
> On 4/18/20 6:45 PM, gentoo_esh...@tutanota.com wrote:
>
>>
>>
>> The code that allows 'read -p' to be interrupted when posixly_correct, must
>> then be somewhere else, I shall keep lookin', yet I fear I might not find it
>> :-"
>>
>
> Look in read
Date:Sun, 19 Apr 2020 15:40:39 -0400
From:Chet Ramey
Message-ID: <8c5bdd2c-bc61-a885-6a05-690ef7f51...@case.edu>
| Nobody, including POSIX, is rational, then.
There is no %q in POSIX printf currently, so the issue
does not arise there, and in any case, its objectiv
2020-04-19 23:54 George Jones :
> It looks like hash_search just does a linear walk if array entries
> to find elements in a list.
https://eludom.github.io/blog/20200418/
> and there it is, the linear search walking the list in hash_search()
>
> ```
> [...]
>
> bucket = HASH_BUCKET (string, tabl
On 4/19/20 10:53 AM, George Jones wrote:
> It looks like hash_search just does a linear walk if array entries to find
> elements in a list. This slows down (order N?) new inserts when the
> number of entries gets large.
Well, that's the collision handling mechanism. You have to have one. If the
On 4/17/20 6:37 PM, Robert Elz wrote:
> This happens only because of the cheap way we (and I presume you)
> implement things - in any rational scheme, it would take the precision
> chars from the source string, and then quote them.
Nobody, including POSIX, is rational, then.
--
``The lyf so sho
On 4/17/20 4:38 PM, Sam Liddicott wrote:
> So is it to be "fixed" in the documentation with a warning that
> truncating-size specifiers for %q may nullify the safety benefits for which
> it is used?
Probably something more general, along the lines of the POSIX language for
the %b directive:
"Byte
On 4/18/20 6:45 PM, gentoo_esh...@tutanota.com wrote:
>
>
>
> Apr 18, 2020, 23:41 by gentoo_esh...@tutanota.com:
>
>>
>> On another note, I naively tried to patch out the POSIX requirement, for my
>> own/local_use puposes but had no effect:
>> in this code
>> + /* posix mode SIGINT during rea
On 4/18/20 5:41 PM, gentoo_esh...@tutanota.com wrote:
> can confirm that indeed `bash --posix` does interrupt the 'read -p' on first
> C-c, however, the inside-trap seen exit code is 0, but if the trap doesn't
> `exit` itself, then the exit code after the 'read -p' is seen correctly as
> 130, i
On 4/17/20 5:31 AM, DALECKI Léo wrote:
> Bash Version: 4.4
> Patch Level: 20
> Release Status: release
>
> Description:
> A trap set with an external call in a command substitution seems to
> break the parent Bash shell.
Thanks for the report. This is a race condition -- the parent shell han
It looks like hash_search just does a linear walk if array entries to find
elements in a list. This slows down (order N?) new inserts when the
number of entries gets large.
Would there be any interest in merging a patch to add an option for making
this faster (maybe using b-trees?)
My analysis
13 matches
Mail list logo
