unset builtin behaves differently from bash manual
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: x86_64-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' -DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin' -DSYS_BASHRC='/etc/bash/bashrc' -DSYS_BASH_LOGOUT='/etc/bash/bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -march=core2 -O2 -pipe -mtune=generic uname output: Linux qiaomuf-laptop 2.6.36-gentoo-r8 #2 SMP Wed May 11 16:48:09 CST 2011 x86_64 Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz GenuineIntel GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.1 Patch Level: 9 Release Status: release Description: We haven't checked bash-4.0 but for bash-4.1 and later, without options, unset first tries to unset a variable, and if that fails, tries to unset a function. However, The manual still states the old behavior. Repeat-By: always Fix: fix the manual -- Best wishes, Mu Qiao Gentoo Linux Developer GnuPG fingerprint: 92B1 B0C4 8D14 F8C4 EFA5 3ACC 30B3 0DE4 17B1 57E9 signature.asc Description: OpenPGP digital signature
Bash 4.2 crashes with "git gc" from git 1.7.5.3
Configuration Information [Automatically generated, do not change]: Machine: i586 OS: linux-gnu Compiler: gcc -I/usr/src/packages/BUILD/bash-4.2 -L/usr/src/packages/BUILD/bash-4.2/../readline-6.2 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-suse-linux-gnu' -DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -g -std=gnu89 -Wuninitialized -Wextra -Wno-unprototyped-calls -Wno-switch-enum -Wno-unused-variable -Wno-unused-parameter -ftree-loop-linear -pipe -fprofile-use uname output: Linux duo 2.6.37.6-0.5-desktop #1 SMP PREEMPT 2011-04-25 21:48:33 +0200 i686 i686 i386 GNU/Linux Machine Type: i586-suse-linux-gnu Bash Version: 4.2 Patch Level: 10 Release Status: release Description: Invoking "git gc" causes bash to crash with the following error: *** glibc detected *** /bin/sh: free(): invalid pointer: 0x080f7230 *** === Backtrace: = /lib/libc.so.6(+0x6de2b)[0xb753ce2b] /lib/libc.so.6(cfree+0xd9)[0xb7541ad9] /bin/sh[0x80baa7a] /bin/sh(glob_vector+0x947)[0x80bb4a7] /bin/sh(glob_filename+0xa6)[0x80bb676] /bin/sh(shell_glob_filename+0x49)[0x8094d59] /bin/sh[0x80900a3] /bin/sh(execute_command_internal+0x3fa)[0x807101a] /bin/sh(execute_command+0x61)[0x8074c81] /bin/sh(reader_loop+0xcb)[0x8060aeb] /bin/sh(main+0xc5f)[0x805f25f] /lib/libc.so.6(__libc_start_main+0xfe)[0xb74e5c2e] /bin/sh[0x805ff99] Repeat-By: Install bash 4.2 and git 1.7.5.3 and run bash # Clone a very small test repository git clone git://anongit.kde.org/scratch/cfeck/containmentaction-favorites.git cd containmentaction-favorites git gc
Re: unset builtin behaves differently from bash manual
On 5/27/11 10:15 AM, Mu Qiao wrote: > Bash Version: 4.1 > Patch Level: 9 > Release Status: release > > Description: > We haven't checked bash-4.0 but for bash-4.1 and later, without > options, unset first tries to unset a variable, and if that fails, tries > to unset a function. However, The manual still states the old behavior. Thanks for the report. I will clarify the documentation. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash 4.2 crashes with "git gc" from git 1.7.5.3
On 5/28/11 12:52 PM, p...@duo.site wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i586 > OS: linux-gnu > Compiler: gcc -I/usr/src/packages/BUILD/bash-4.2 > -L/usr/src/packages/BUILD/bash-4.2/../readline-6.2 > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-suse-linux-gnu' > -DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL > -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -fomit-frame-pointer > -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector > -funwind-tables -fasynchronous-unwind-tables -g -D_LARGEFILE64_SOURCE > -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -g -std=gnu89 > -Wuninitialized -Wextra -Wno-unprototyped-calls -Wno-switch-enum > -Wno-unused-variable -Wno-unused-parameter -ftree-loop-linear -pipe > -fprofile-use > uname output: Linux duo 2.6.37.6-0.5-desktop #1 SMP PREEMPT 2011-04-25 > 21:48:33 +0200 i686 i686 i386 GNU/Linux > Machine Type: i586-suse-linux-gnu > > Bash Version: 4.2 > Patch Level: 10 > Release Status: release > > Description: > Invoking "git gc" causes bash to crash with the following error: > > *** glibc detected *** /bin/sh: free(): invalid pointer: 0x080f7230 *** > === Backtrace: = > /lib/libc.so.6(+0x6de2b)[0xb753ce2b] > /lib/libc.so.6(cfree+0xd9)[0xb7541ad9] > /bin/sh[0x80baa7a] > /bin/sh(glob_vector+0x947)[0x80bb4a7] > /bin/sh(glob_filename+0xa6)[0x80bb676] > /bin/sh(shell_glob_filename+0x49)[0x8094d59] > /bin/sh[0x80900a3] > /bin/sh(execute_command_internal+0x3fa)[0x807101a] > /bin/sh(execute_command+0x61)[0x8074c81] > /bin/sh(reader_loop+0xcb)[0x8060aeb] > /bin/sh(main+0xc5f)[0x805f25f] > /lib/libc.so.6(__libc_start_main+0xfe)[0xb74e5c2e] > /bin/sh[0x805ff99] > > Repeat-By: > Install bash 4.2 and git 1.7.5.3 and run bash > # Clone a very small test repository > git clone > git://anongit.kde.org/scratch/cfeck/containmentaction-favorites.git > cd containmentaction-favorites > git gc I can't reproduce this with git 1.7.4.4 on Fedora 14. Does it happen with all versions of git, or just 1.7.5.3? Can we get a better stack traceback, like from running gdb on the core file? Most important, can other people reproduce the crash? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: incorrect associative array key parsing if they contain closing square bracket
> associative array key parsing seems to be incorrect if they contain
> closing square bracket inside the array=([key]=value) construct.
>
> the following testcase :
>
> $ declare -A key_full; key_full=(["version[agent]"]=agent.version); echo
> "${!key_full[@]}"
Yes, this is a problem. Thanks for the report. As a workaround,
key_full["version[agent]"]=agent.version
works correctly.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash source repository
Chet Ramey wrote on 2009-11-02: > Jari Aalto was setting up a git repository of current and older bash > versions on savannah. I'll keep him up to date with public versions > of bash Bob Proulx wrote on 2009-11-02: >> It looks like it has just recently been partially implemented. >> http://git.savannah.gnu.org/cgit/bash.git >> But only at the major release points. No patches have been applied. >> But the available history seems to all be there. Jan Schampera wrote on 2009-11-22: >>> The official patches should be there as individual commits. Though, >>> I admit it's not a small amount of work to do all that for the past >>> releases. Chet Ramey wrote on 2009-11-23: > All the release tarfiles and official patches dating back to at least > bash-1.14 are on ftp.gnu.org in pub/gnu/bash (though the form of the > patches has changed). This is at least a 15-year chronology. Eric Blake wrote on 2010-03-13: the savannah repository is tracking only public releases and patches (and could use some TLC in reflecting recent patches, or even being modified to show patches in finer granularity). It's been two years since this discussion began, and a year since this thread was alive on the mailing list. I did some research this weekend and collected all the old versions of Bash I could find. I've carefully organized all this into a repository, making the commits as find-grained as possible given what's available in the permanent public record. My work is available at: https://gitorious.org/bash/bash I humbly suggest that http://git.savannah.gnu.org/cgit/bash.git be replaced with this repository above that I've created. The new repository contains everything that the current Savannah one does, but I put much more effort into making commits fine-grained, rather than merely importing the public releases blindly. (For example, I did 'git mv' where it was obvious a move occurred, so that changes in file movements were properly tracked historically). I'm also willing to maintain the git repository going forward, both on savannah and gitorious. Would folks like me to do this? Finally, I wish I had older data, particularly versions before 1.05, and also intermediate releases before 1.14. If anyone has any such versions, please let me know, and I'll rebase the master branch on top of them. -- -- bkuhn
Re: Bash source repository
On Sunday, May 29, 2011 22:18:33 Bradley M. Kuhn wrote: > It's been two years since this discussion began and there have been requests older than that. you just found the most "recent". -mike signature.asc Description: This is a digitally signed message part.
Re: Bash source repository
On Mon, May 30, 2011 at 02:18, Bradley M. Kuhn wrote: > Chet Ramey wrote on 2009-11-02: >> Jari Aalto was setting up a git repository of current and older bash >> versions on savannah. I'll keep him up to date with public versions >> of bash > > Bob Proulx wrote on 2009-11-02: >>> It looks like it has just recently been partially implemented. >>> http://git.savannah.gnu.org/cgit/bash.git >>> But only at the major release points. No patches have been applied. >>> But the available history seems to all be there. > > Jan Schampera wrote on 2009-11-22: The official patches should be there as individual commits. Though, I admit it's not a small amount of work to do all that for the past releases. > > Chet Ramey wrote on 2009-11-23: >> All the release tarfiles and official patches dating back to at least >> bash-1.14 are on ftp.gnu.org in pub/gnu/bash (though the form of the >> patches has changed). This is at least a 15-year chronology. > > Eric Blake wrote on 2010-03-13: > the savannah repository is tracking only public releases and > patches (and could use some TLC in reflecting recent patches, or > even being modified to show patches in finer granularity). > > It's been two years since this discussion began, and a year since this > thread was alive on the mailing list. > > I did some research this weekend and collected all the old versions of Bash > I could find. I've carefully organized all this into a repository, > making the commits as find-grained as possible given what's available in > the permanent public record. My work is available at: > https://gitorious.org/bash/bash > > I humbly suggest that http://git.savannah.gnu.org/cgit/bash.git be > replaced with this repository above that I've created. The new > repository contains everything that the current Savannah one does, but I > put much more effort into making commits fine-grained, rather than > merely importing the public releases blindly. (For example, I did 'git > mv' where it was obvious a move occurred, so that changes in file > movements were properly tracked historically). > > I'm also willing to maintain the git repository going forward, > both on savannah and gitorious. Would folks like me to do this? > > Finally, I wish I had older data, particularly versions before 1.05, and > also intermediate releases before 1.14. If anyone has any such > versions, please let me know, and I'll rebase the master branch on top > of them. As I recall, the diffs for versions prior to the 1.14.3 tarball produce incorrect results (somewhat silently), so those commits are essentially going to be junk. In any case, it is my opinion that all further development should take place through a public, distributed repository such as the one you have created - regardless of Chet's objections. If Chet is not on board, then I suggest working to establish a new official maintainer. Part of being a maintainer is using tools that benefit and properly recognize the contributors; private repos, ancient patch formats, and attribution through [only] ChangeLogs are unnacceptable ways to work these days.
Re: Bash source repository
I wrote earlier this evening: > > I humbly suggest that http://git.savannah.gnu.org/cgit/bash.git be > > replaced with this repository above that I've created. The new > > repository contains everything that the current Savannah one does, but I > > put much more effort into making commits fine-grained, rather than > > merely importing the public releases blindly. (For example, I did 'git > > mv' where it was obvious a move occurred, so that changes in file > > movements were properly tracked historically). > > > > I'm also willing to maintain the git repository going forward, > > both on savannah and gitorious. Would folks like me to do this? Michael Witten replied a few minutes ago: > it is my opinion that all further development should take place through > a public, distributed repository such as the one you have created - > regardless of Chet's objections. It seems that two different conversations have been conflated here. My goal was to simply finish what Jari was seeking to do with http://git.savannah.gnu.org/cgit/bash.git two years ago. I believe I have succeed in that: specifically, putting all the historical information currently available into a single git repository. I'm also offering to maintain the same indefinitely. What you've raised another issue entirely that perhaps should be discussed, but I hope it won't be conflated with what I was trying to do by creating the Git repository. It's true that perhaps this Git repository I created could be used as a basis to explore what you are proposing, but the two issues are ultimately only tangentially related. > As I recall, the diffs for versions prior to the 1.14.3 tarball produce > incorrect results (somewhat silently), so those commits are essentially > going to be junk. I think I handled this correctly, as I used both sources from ftp.gnu.org and others I found online to make sure that the 1.14.x were reconstructed correctly. However, if you find something incorrect in the Git history, and have a better source for it that can help to correct it, I'm happy to rebase master against the change. -- bkuhn
Re: Bash source repository
On Mon, May 30, 2011 at 03:09, Bradley M. Kuhn wrote: > > Michael Witten replied a few minutes ago: >> it is my opinion that all further development should take place through >> a public, distributed repository such as the one you have created - >> regardless of Chet's objections. > > It seems that two different conversations have been conflated here. My > goal was to simply finish what Jari was seeking to do with > http://git.savannah.gnu.org/cgit/bash.git two years ago. I believe I have > succeed in that: specifically, putting all the historical information > currently available into a single git repository. I'm also offering to > maintain the same indefinitely. > > What you've raised another issue entirely that perhaps should be > discussed, but I hope it won't be conflated with what I was trying to do > by creating the Git repository. It's true that perhaps this Git > repository I created could be used as a basis to explore what you are > proposing, but the two issues are ultimately only tangentially related. I take full responsibility for accusations of mutiny :-)
Re: Bash source repository
"Bradley M. Kuhn" writes: > The new repository contains everything that the current > Savannah one does, but I put much more effort into making > commits fine-grained, rather than merely importing the public > releases blindly. (For example, I did 'git mv' where it was > obvious a move occurred, so that changes in file movements were > properly tracked historically). Git doesn't track file movement in any way, it just tracks file content. It is "git diff" and other commands for viewing history that figure out that a file moved, based on the change that occurred. It is a waste of time to use "git mv" if some other way is easier. -- Ben Pfaff http://benpfaff.org
Re: Bash source repository
On Mon, May 30, 2011 at 05:06, Ben Pfaff wrote: > "Bradley M. Kuhn" writes: > >> The new repository contains everything that the current >> Savannah one does, but I put much more effort into making >> commits fine-grained, rather than merely importing the public >> releases blindly. (For example, I did 'git mv' where it was >> obvious a move occurred, so that changes in file movements were >> properly tracked historically). > > Git doesn't track file movement in any way, it just tracks file > content. It is "git diff" and other commands for viewing history > that figure out that a file moved, based on the change that > occurred. It is a waste of time to use "git mv" if some other > way is easier. More importantly, it is best to move files and commit the results without any other additional content changes occuring simultaneously, so that commands like "git diff" may figure this out more readily. Perhaps (and hopefully) Bradley meant that file moves were separated from any other content changes that might otherwise have occurred simultaneously. P.S. Ben, it is generally a good idea to maintain the `Cc' list unless explicitly asked.
