Re: Resolving quoted COMP_CWORD on bash-4
Freddy Vulto wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i686 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' > -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include > -I./lib -g -O2 > uname output: Linux myhost 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 > 18:40:08 UTC 2009 i686 GNU/Linux > Machine Type: i686-pc-linux-gnu > > Bash Version: 4.0 > Patch Level: 28 > Release Status: release > > On bash-4, when completing: > > $ a 'b c > > The COMP_CWORD variables contain: > > COMP_CWORD: 3 > COMP_CWORDS: > 0: a > 1: ' > 2: b > 3: c > > Whereas on bash-3 they contained: > > COMP_CWORD: 1 > COMP_CWORDS: > 0: a > 1: 'b c > > I know that bash-4 has changed: > > i. The programmable completion code now uses the same >set of characters as readline when breaking the command >line into a list of words. That change in how quoted words are treated was unintended, and clearly a bug. I will fix it, and the fix will be in bash-4.1. It may also be released as a patch; I have to see how extensive the changes will be. 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: globstar: **/foo*/ matches all directories, even ones not named foo*
Anders Kaseorg wrote: > Bash Version: 4.0 > Patch Level: 33 > Release Status: release > > Description: > With the globstar option enabled, bash seems to misinterpret > other wildcard path components between a **/ and the last / as > matching any path, even if the path doesn't match the > wildcard. Thanks for the report. I will release a fix for this as a patch to bash-4.0. 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/
$() parsing still broken
Even in the latest bash, 4.0.33, $() parsing is still broken: $ bash -c 'echo $(echo \|)' bash: -c: line 0: unexpected EOF while looking for matching `)' bash: -c: line 1: syntax error: unexpected end of file And yes, this is bash built with GNU bison, not Berkeley yacc. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: $() parsing still broken
Christian Weisgerber writes: > Even in the latest bash, 4.0.33, $() parsing is still broken: > > $ bash -c 'echo $(echo \|)' > bash: -c: line 0: unexpected EOF while looking for matching `)' > bash: -c: line 1: syntax error: unexpected end of file This has been fixed with patch 1, are you sure you are running the patched version? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
