Fra: Chet Ramey
>On 12/5/23 6:46 PM, Ole Tange via Bug reports for the GNU Bourne Again
SHell wrote:
>> For the (admitedly weirdly named) dirs below TAB completion does not
>> work correctly.
>Thanks for the report. Where did you encounter these directory names?
T
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Linux aspire 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56
UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash
On Mon, Sep 23, 2019 at 3:53 PM Chet Ramey wrote:
>
> On 9/23/19 5:29 AM, Ilkka Virta wrote:
> > On 22.9. 21:15, Chet Ramey wrote:
> >> On 9/20/19 10:24 PM, hk wrote:
> >>
> >>> Description:
> >>> On the section 3.2.6(GNU Parallel, page 16 in the pdf) of Bash
> >>> Reference Manual. The m
On Fri, Apr 19, 2019 at 3:16 PM Chet Ramey wrote:
> On 4/19/19 4:21 AM, Ole Tange wrote:
> > Reading https://www.gnu.org/prep/standards/standards.html#Semantics
> >
> > """Avoid arbitrary limits on the length or number of any data
> > structure, including
On Fri, Apr 12, 2019 at 7:18 PM Andrew Church wrote:
>
> >This recursive function causes bash to segfault:
> >
> >$ re() { t=$((t+1)); if [[ $t -gt 800 ]]; then echo foo; return;
> >fi; re; }; re
> >Segmentation fault (core dumped)
> >
> >Ideally Bash ought to run out of memory before this fai
This recursive function causes bash to segfault:
$ re() { t=$((t+1)); if [[ $t -gt 800 ]]; then echo foo; return;
fi; re; }; re
Segmentation fault (core dumped)
Ideally Bash ought to run out of memory before this fails. But an
acceptable solution could also be to say 'stack overflow'.
$ bash
On Mon, Jan 7, 2019 at 9:37 AM Eduardo A. Bustamante López
wrote:
> On Mon, Jan 07, 2019 at 08:15:12AM +0100, Ole Tange wrote:
> > On Mon, Jan 7, 2019 at 12:08 AM Chet Ramey wrote:
> > > On 1/5/19 3:12 PM, Eduardo A. Bustamante López wrote:
> > > > On Fri, Dec 28,
On Mon, Jan 7, 2019 at 12:08 AM Chet Ramey wrote:
>
> On 1/5/19 3:12 PM, Eduardo A. Bustamante López wrote:
> > On Fri, Dec 28, 2018 at 10:24:50AM +0100, Ole Tange wrote:
> > (...)
> >> Patch attached.
:
> > - Does the new RNG generate uniformly distributed
On Sat, Jan 5, 2019 at 9:14 PM Eduardo A. Bustamante López
wrote:>
> On Fri, Dec 28, 2018 at 10:24:50AM +0100, Ole Tange wrote:
> (...)
> > Patch attached.
:
> I applied the Salsa20 RNG patch (slightly modified due to the recent changes
> in
> variables.c, attached [
On Mon, Dec 31, 2018 at 8:12 PM Chet Ramey wrote:
:
> Thanks for the patch. I'll take a look after I release bash-5.0. One
> question: can you reproduce the same random sequence by using the same
> seed? That's for backwards compatibility, even if the sequences themselves
> differ.
Yes. Seeding w
On Sun, Dec 16, 2018 at 6:41 AM Eduardo Bustamante wrote:
:
> You know no one is stopping you from submitting a patch to actually
> fix the documentation right? (or maybe, you know, submitting an actual
> working patch to change the random generator, not just drop some
> irrelevant code snippet yo
On Mon, Dec 3, 2018 at 9:18 PM Chet Ramey wrote:
> On 12/3/18 11:31 AM, Ole Tange wrote:
> > On Mon, Dec 3, 2018 at 3:56 PM Chet Ramey wrote:
> >
> >> There has to be a compelling reason to change this, especially at a point
> >> so close to a major release.
I
On Mon, Dec 3, 2018 at 3:56 PM Chet Ramey wrote:
> There has to be a compelling reason to change this, especially at a point
> so close to a major release.
The reason for my submission was that I needed a bunch of random
numbers in a shell script, but I needed them to be high quality.
Luckily I
On Wed, Nov 21, 2018 at 11:45 PM Chet Ramey wrote:
> On 11/21/18 3:07 PM, Ole Tange wrote:
> > 'brand' in variables.c is comparable in size to ChaCha20 and ChaCha20
> > is not completely broken:
> > https://en.wikipedia.org/wiki/Salsa20
> >
> > Co
'brand' in variables.c is comparable in size to ChaCha20 and ChaCha20
is not completely broken:
https://en.wikipedia.org/wiki/Salsa20
Could we please replace 'brand' with ChaCha20?
/Ole
GNU Parallel can today successfully transfer bash environment values
through ssh to the remote host:
FOO=xyz
export FOO
parallel --env FOO -S server 'echo $FOO' ::: bar
But I would like to be able to transfer functions, too. Right now they
work locally:
myfunc() { echo This is a fu
On Sat, May 12, 2012 at 9:34 AM, Linda Walsh wrote:
>
> Ole Tange wrote:
>
>> Can you explain how that idea would differ from sem (Part of GNU
>> Parallel)?
>
> Because gnu parallel is written in perl? And well, writing it in
> perl that's near eas
On Thu, 3 May 2012 19:49:37, Colin McEwan wrote:
> I frequently find myself these days writing shell scripts, to run on
> multi-core machines, which could easily exploit lots of parallelism (eg. a
> batch of a hundred independent simulations).
>
> The basic parallelism construct of '&' for async e
On Thu, May 19, 2011 at 03:23:55PM +0200, Rafael Fourquet wrote:
> I have a program which outputs groups of filenames. Each group is separated
> by a newline, and within each group,
> each name is separated by '\0'.
Use GNU Parallel:
printf "ole\0tange\nfafael\0fourquet\n" | parallel --colsep '\0
19 matches
Mail list logo
