Re: Assignment of $* to a var removes spaces on unset IFS.

Date:Mon, 13 Aug 2018 21:36:23 -0400 From:Bize Ma Message-ID: | You both are confused. The original table included You misinterpreted my message. I said two independant things ... first that the bug is already fixed. I didn't say that the fixed version was relea

Re: Assignment of $* to a var removes spaces on unset IFS.

On Tue, Aug 14, 2018 at 6:18 AM Eduardo A. Bustamante López < dual...@gmail.com> wrote: > On Mon, Aug 13, 2018 at 10:52:20PM -0400, Bize Ma wrote: > (...) > > That version is not even beta, it is still alpha, are you asking that > > everyone should use > > non-released (and not yet tested as beta)

Re: Assignment of $* to a var removes spaces on unset IFS.

On Mon, Aug 13, 2018 at 09:36:23PM -0400, Bize Ma wrote: > Note that 4.4.19 is newer than what is available in > https://www.gnu.org/software/bash/ The current patch level of bash can be obtained by downloading the most recent tarball from and then applying the subse

Re: Extglob *?(a)b matches every string

On 8/12/18 12:26 AM, Mark Polyakov wrote: >Bash Version: 4.3 >Patch Level: 46 >Release Status: release >A >Description: >A A A An extglob pattern such as `*?(anything)something_else` will >match any string, even though it should only match strings that end >with so

Re: Unexpected delay in using arguments.

On 8/12/18 3:16 AM, Bize Ma wrote: > Try this script: > >     #!/bin/bash >     TIMEFORMAT='%R' > >     n=1000 >     m=2 > >     f1   () { :; } > >     f2   () { i=0;  time while [ "$((i+=1))" -lt "$n" ]; do     :    ; done >           i=0;  time while [ "$((i+=1))" -lt "$n" ]; do     f1   

"sh -a" sets the POSIXLY_CORRECT *environment* variable

Hi, This is from https://unix.stackexchange.com/questions/462333/why-does-a-in-bin-sh-a-affect-sed-and-set-a-doesnt (original investigation by Mark Plotnick) Though not documented, enabling the POSIX mode in bash whether with - bash -o posix - sh - env SHELLOPTS=posix bash - set -o posix # withi

Re: Unexpected delay in using arguments.

I followed along through the script: > m=2 ... > test1() { ... Eventually I got to this line: > set -- $(seq $m) At that line I see that bash must allocate enough memory to hold all of the numbers from 1 through 2 in memory all at one time. That is very inefficient. That

Re: Unexpected delay in using arguments.

2018-08-14 11:25:04 -0400, Chet Ramey: [...] > If you build a profiling version of bash, you'll find that about 75% of > that time is spent copying the list of arguments around, since you have > to save and restore it each time you call f1. Looking at making that more > efficient has been a low-lev

Re: Assignment of $* to a var removes spaces on unset IFS.

2018-08-13 23:17 GMT-04:00 Eduardo A. Bustamante López : > On Mon, Aug 13, 2018 at 10:52:20PM -0400, Bize Ma wrote: > (...) My point is that, in the context of bug reports, it's > important that you always test against the *unreleased* version of the > code, > Not if the version to test is the re

Re: Unexpected delay in using arguments.

2018-08-14 11:25 GMT-04:00 Chet Ramey : > On 8/12/18 3:16 AM, Bize Ma wrote: > > Try this script: > (...) > Which is a thousand times slower. > > If you build a profiling version of bash, you'll find that about 75% of > that time is spent copying the list of arguments around I just don't see wh

Re: Unexpected delay in using arguments.

> Of course I assume this is only a proxy simpler reproducer > for the actual problem program Of course this is a "reproducer" of the issue. > but just the same it is almost always possible > to refactor a program into a different algorithm that avoids the need > to enumerate so many arguments in