On Wed, Apr 27, 2022, 20:30 Chet Ramey wrote:
> On 4/27/22 2:01 PM, Jason A. Donenfeld wrote:
> > ---
> > lib/glob/glob.c | 2 +-
> > locale.c| 10 +-
> > 2 files changed, 6 insertions(+), 6 deletions(-)
>
> Thanks for the patch.
>
> &
---
lib/glob/glob.c | 2 +-
locale.c| 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/glob/glob.c b/lib/glob/glob.c
index eb6277f0..cadabba9 100644
--- a/lib/glob/glob.c
+++ b/lib/glob/glob.c
@@ -120,7 +120,7 @@ void udequote_pathname PARAMS((char *));
v
Single quotes with the nested double quote? That's nuts. But okay. I
guess there really is some double expansion eval-like logic happening
with the unset operator.
This behavior is quite surprising:
$ declare -A blah
$ blah['$(DOESNOTEXIST)']=broken
$ for i in "${!blah[@]}"; do echo "$i"; done
$(DOESNOTEXIST)
$ for i in "${!blah[@]}"; do unset blah["$i"]; done
bash: DOESNOTEXIST: command not found
bash: unset: [$(DOESNOTEXIST)]: bad array subscript
I wouldn
On Thu, Aug 6, 2020 at 4:49 PM Chet Ramey wrote:
>
> On 8/6/20 10:36 AM, Jason A. Donenfeld wrote:
> > Hi Chet,
> >
> > On Thu, Aug 6, 2020 at 4:30 PM Chet Ramey wrote:
> >>
> >> On 8/6/20 6:05 AM, Jason A. Donenfeld wrote:
> >>> Hi,
> &
Hi Chet,
On Thu, Aug 6, 2020 at 4:30 PM Chet Ramey wrote:
>
> On 8/6/20 6:05 AM, Jason A. Donenfeld wrote:
> > Hi,
> >
> > It may be a surprise to some that this code here winds up printing
> > "done", always:
> >
> > $ cat a.bash
> > set
On Thu, Aug 6, 2020 at 2:14 PM Jason A. Donenfeld wrote:
>
> On Thu, Aug 6, 2020 at 1:15 PM Oğuz wrote:
> >
> >
> >
> > 6 Ağustos 2020 Perşembe tarihinde Jason A. Donenfeld
> > yazdı:
> >>
> >> Hi,
> >>
> >> It may be a su
On Thu, Aug 6, 2020 at 1:15 PM Oğuz wrote:
>
>
>
> 6 Ağustos 2020 Perşembe tarihinde Jason A. Donenfeld yazdı:
>>
>> Hi,
>>
>> It may be a surprise to some that this code here winds up printing
>> "done", always:
>>
>> $ cat a.bas
Hi,
It may be a surprise to some that this code here winds up printing
"done", always:
$ cat a.bash
set -e -o pipefail
while read -r line; do
echo "$line"
done < <(echo 1; sleep 1; echo 2; sleep 1; false; exit 1)
sleep 1
echo done
$ bash a.bash
1
2
done
The reason for this is that proces
On Mon, Jun 22, 2020 at 2:16 PM Ilkka Virta wrote:
>
> On 22.6. 19.35, Chet Ramey wrote:
> > On 6/22/20 1:53 AM, Jason A. Donenfeld wrote:
> >> Currently a static sized buffer is used for reading files. At the moment
> >> it is extremely small, making parsing
Hi Chet,
A little bit larger than 1024, I believe, so 2048 would be reasonable.
However, consider taking this patch as-is with the 4096 page size.
This will yield much better performance and have basically no
drawbacks on any system.
Another place lbuf should be increased is in zcatfd, by the wa
.
Signed-off-by: Jason A. Donenfeld
---
lib/sh/zread.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/sh/zread.c b/lib/sh/zread.c
index 8dd78102..f1389887 100644
--- a/lib/sh/zread.c
+++ b/lib/sh/zread.c
@@ -117,7 +117,7 @@ zreadintr (fd, buf, len)
in read(2). This does
Were you planning on committing this to Savannah?
On Mon, Apr 20, 2020 at 3:58 PM Chet Ramey wrote:
> OK, good. It was either that or closing the fd after reaping the child
> process -- I couldn't tell 100% from the system call trace.
The latter is an interesting possibility. I assume SIGCHLD comes in
through a signal handler, so it's asynchrono
On Mon, Apr 20, 2020 at 3:49 PM Chet Ramey wrote:
>
> On 4/20/20 5:01 PM, Jason A. Donenfeld wrote:
> > On 4/20/20, Chet Ramey wrote:
> >> On 4/20/20 1:15 AM, Jason A. Donenfeld wrote:
> >>> Hi,
> >>>
> >>> I've uncovered a very un
This one will reproduce immediately:
#!/bin/bash
set -e
a="my name is a"
b="my name is b"
sleep() { read -t "$1" -N 1 || true; }
doit() { sleep 0.1; "$@"; }
while true; do
doit cat <(echo "$a") <(echo "$b")
done
Here's a simpler reproducer:
set -e
a="my name is a"
b="my name is b"
pretty() { echo -e "\x1b[0m"; }
doit() { pretty; "$@"; }
while true; do
doit cat <(echo "$a") <(echo "$b")
done
On 4/20/20, Chet Ramey wrote:
> On 4/20/20 1:15 AM, Jason A. Donenfeld wrote:
>> Hi,
>>
>> I've uncovered a very unusual race condition when using process
>> substitution and developed as minimal a reproducer as I could create:
>
> What version of bash are you using?
>
5.0.016
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
I keep forgetting things. The other thing I wanted to bring up is that
I suspect bash's actual implementation of temporary files is
problematic and might have some of the classic /tmp and TOCTOU style
attacks. The current implementation is three-fold via ifdefs:
char *
sh_mktmpname (nameroot, flag
On Thu, Apr 11, 2019 at 6:02 AM Jason A. Donenfeld wrote:
> curious about is - what about internally treating "x <
Hi Chet,
On Wed, Apr 10, 2019 at 3:07 PM Chet Ramey wrote:
> This is unnecessary hyperbole. The existing file-based mechanism works
> just fine. We're talking about what's essentially an optimization.
> [...]
> This doesn't make any sense.
> [...]
> There isn't an "insecure path."
I'm a bit late
Since originally raising this issue with dkg (leading to this email
thread), I've only followed along from a bit of a distance. But it does
look like there's been some good progress: there's now a commit that
fills the pipe up to the OS's maximum pipe size, and then falls back to
the old (buggy, vu
23 matches
Mail list logo
