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 *));
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
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
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
.
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
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 unu
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,
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
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,
23 matches
Mail list logo
