Re: Assignment of $* to a var removes spaces on unset IFS.
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) alpha release ? (...) I didn't say that. My point is that, in the context of bug reports, it's important that you always test against the *unreleased* version of the code, since that's where most bug fixes are queued up (or at least the ones that break backwards compatibility). > So? It is not solved in that thread, it is even said that: > > > This is a bug in bash and it should be fixed, not excused. > > To which I agree. After a year, nothing else have been said about it. > For some reason the threading broke in the archive browser. Here's the response from Chet: http://lists.nongnu.org/archive/html/bug-bash/2017-10/msg00023.html The fix for this issue is already in the Git repository (devel branch) and in Bash 5.0. I cannot answer for Chet, but please consider this: The fix for this bug breaks backwards compatibility, so that means it cannot be a patch-level fix for 4.4. It should either be a minor version increase (4.5) or go into the next major release, which is 5.0 (which was already declared alpha state, and includes the fix). > It seems about time to get it solved. Or say that it won't be. Again, it's fixed already and the fix is scheduled to go out in the next release (5.0). Given that, do you think this bug is severe enough to have to issue a new minor version just for it? (4.5), or can we just wait for 5.0 to come out which fixes this and a bunch of other bugs? (see the CHANGES file, in particular, entry `oo', http://git.savannah.gnu.org/cgit/bash.git/diff/CHANGES?h=bash-5.0-testing=9a51695bed07d37086c352372ac69d0a30039a6b)
Re: Assignment of $* to a var removes spaces on unset IFS.
2018-08-13 22:09 GMT-04:00 Eduardo A. Bustamante López : > On Mon, Aug 13, 2018 at 09:36:23PM -0400, Bize Ma wrote: > (...) > > Please, do not waste our time in incorrect claims. > > > > Do your homework and test ! > (...) > > > dualbus@ubuntu:~/src/gnu/bash$ bash /tmp/script > 4.4.19(1)-release > [foo bar baz quux][ foo bar baz quux ] > > So, it is confirmed that the bug exists in the present release, Is it not? > Did you test Bash 5.0? Because that's where the current bug fixes are going to. So, is it a "wont fix" for 4.4 (present release) ? > I don't see Chet releasing a new version of 4.4 to fix something that's already > fixed there. 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) alpha release ? > dualbus@ubuntu:~/src/gnu/bash$ cat /tmp/script > echo $BASH_VERSION > set -- " foo "" bar baz " " quux " > unset IFS > a=$* > b="$*" > printf '[%s]' "$a" "$b"; echo Thanks for copying the supplied script. > dualbus@ubuntu:~/src/gnu/bash$ ./bash /tmp/script > 5.0.0(1)-alpha > [ foo bar baz quux ][ foo bar baz quux ] > > Thanks for testing. !! > Please read this thread: > > * http://lists.nongnu.org/archive/html/bug-bash/2017-09/msg00058.html > So? It is not solved in that thread, it is even said that: > This is a bug in bash and it should be fixed, not excused. To which I agree. After a year, nothing else have been said about it. It seems about time to get it solved. Or say that it won't be.
Re: Assignment of $* to a var removes spaces on unset IFS.
On Mon, Aug 13, 2018 at 09:36:23PM -0400, Bize Ma wrote: (...) > Please, do not waste our time in incorrect claims. > > Do your homework and test ! (...) Did you test Bash 5.0? Because that's where the current bug fixes are going to. I don't see Chet releasing a new version of 4.4 to fix something that's already fixed there. dualbus@ubuntu:~/src/gnu/bash$ cat /tmp/script echo $BASH_VERSION set -- " foo "" bar baz " " quux " unset IFS a=$* b="$*" printf '[%s]' "$a" "$b"; echo dualbus@ubuntu:~/src/gnu/bash$ bash /tmp/script 4.4.19(1)-release [foo bar baz quux][ foo bar baz quux ] dualbus@ubuntu:~/src/gnu/bash$ ./bash /tmp/script 5.0.0(1)-alpha [ foo bar baz quux ][ foo bar baz quux ] Please read this thread: * http://lists.nongnu.org/archive/html/bug-bash/2017-09/msg00058.html
Re: Assignment of $* to a var removes spaces on unset IFS.
2018-08-13 21:16 GMT-04:00 Eduardo Bustamante : > On Mon, Aug 13, 2018 at 5:25 PM Robert Elz wrote: > [...] > > What's more, reporting bugs in bash 4.3 is just a waste of everyone's > time. > > Upgrade to (at least) the current released version, and use that instead. > > Adding to this point: > > * bash 4.3 was released 4 years ago (2014-02-26) > * bash 4.4 is the current release of bash (2016-09-15) > * bash 5.0 is in alpha state (2018-05-22) > > You both are confused. The original table included > b43sh : [foo bar baz quux][ foo bar baz quux ] > b44sh : [foo bar baz quux][ foo bar baz quux ] That's 4.3.48(2)-release and4.4.19(2)-release Both are failing. Note that 4.4.19 is newer than what is available in https://www.gnu.org/software/bash/ The report is valid for present releases. The bug is still present (since 4.3). Please, do not waste our time in incorrect claims. Do your homework and test ! > I know that some stable Linux distributions might still be > distributing 4.3, but that just means that you have to report the bug > against these distros, not upstream. That is not the problem, don't jump to conclusions.
Re: Assignment of $* to a var removes spaces on unset IFS.
On Mon, Aug 13, 2018 at 5:25 PM Robert Elz wrote: [...] > What's more, reporting bugs in bash 4.3 is just a waste of everyone's time. > Upgrade to (at least) the current released version, and use that instead. Adding to this point: * bash 4.3 was released 4 years ago (2014-02-26) * bash 4.4 is the current release of bash (2016-09-15) * bash 5.0 is in alpha state (2018-05-22) I know that some stable Linux distributions might still be distributing 4.3, but that just means that you have to report the bug against these distros, not upstream.
Re: Assignment of $* to a var removes spaces on unset IFS.
Date:Mon, 13 Aug 2018 11:51:08 -0400 From:Bize Ma Message-ID: | Bash since 4.3 fails to follow what the documentation describes as that on | an assignment values do not undergo splitting or globing. This is already fixed. What's more, reporting bugs in bash 4.3 is just a waste of everyone's time. Upgrade to (at least) the current released version, and use that instead. kre
Assignment of $* to a var removes spaces on unset IFS.
Executing this code: set -- " foo "" bar baz " " quux " unset IFS a=$* b="$*" printf '[%s]' "$a" "$b"; echo Leads to this results in several shells: ash : [ foo bar baz quux ][ foo bar baz quux ] dash: [ foo bar baz quux ][ foo bar baz quux ] b205sh : [ foo bar baz quux ][ foo bar baz quux ] b30sh : [ foo bar baz quux ][ foo bar baz quux ] b32sh : [ foo bar baz quux ][ foo bar baz quux ] b41sh : [ foo bar baz quux ][ foo bar baz quux ] b42sh : [ foo bar baz quux ][ foo bar baz quux ] b43sh : [foo bar baz quux][ foo bar baz quux ] b44sh : [foo bar baz quux][ foo bar baz quux ] bash: [foo bar baz quux][ foo bar baz quux ] posixbash : [foo bar baz quux][ foo bar baz quux ] lksh: [ foo bar baz quux ][ foo bar baz quux ] mksh: [ foo bar baz quux ][ foo bar baz quux ] ksh93 : [ foo bar baz quux ][ foo bar baz quux ] attsh : [ foo bar baz quux ][ foo bar baz quux ] zsh : [ foo bar baz quux ][ foo bar baz quux ] Bash since 4.3 fails to follow what the documentation describes as that on an assignment values do not undergo splitting or globing.
Re: Unexpected delay in using arguments.
Yes Greg, Please read the expanded source question, bash 5 with (and without) bash-malloc has been tested. https://unix.stackexchange.com/q/462084/265604 The problem with arguments is still present. 2018-08-13 9:37 GMT-04:00 Greg Wooledge : > On Sun, Aug 12, 2018 at 03:16:34AM -0400, Bize Ma wrote: > > Which is a thousand times slower. > > Bash 5 is even worse > > Pre-release bash sources use a debugging-friendly (slow) malloc. Or > something. Damn, google is not helping me out here. >
Re: Unexpected delay in using arguments.
On Sun, Aug 12, 2018 at 03:16:34AM -0400, Bize Ma wrote: > Which is a thousand times slower. > Bash 5 is even worse Pre-release bash sources use a debugging-friendly (slow) malloc. Or something. Damn, google is not helping me out here.
Re: Extglob *?(a)b matches every string
On Sat, Aug 11, 2018 at 09:26:56PM -0700, Mark Polyakov wrote: >Bash Version: 4.3 >Patch Level: 46 >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 something_else. This appears to be fixed in bash 4.4.
Re: Rational Range Interpretation for bash-5.0?
On 08/06/2018 03:07 PM, Chet Ramey wrote: Hi. I am considering making bash glob expansion implement rational range interpretation starting with bash-5.0 -- basically making globasciiranges the default. It looks like glibc is going to do this for version 2.28 (at least for a-z, A-Z, and 0-9), and other GNU utilities have done it for some time. What do folks think? I am in favor of the idea provided there is a way to change back to what is now the default. Also, the character order may be extended to use C.utf-8 instead of ASCII to have an stable order for all UNICODE characters. Read https://manpages.debian.org/unstable/open-infrastructure-locales-c.utf-8/locales-c.utf-8.7.en.html
