completion considers equals sign (=) its own word?
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux swboyd-laptop 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:01:29 UTC 2009 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 4.0 Patch Level: 33 Release Status: release Description: When completing options for git I used to be able to get a list of pretty formats by completing the --pretty= option. The option ends in an equals sign, so the completion looks for the word --pretty= in the COMP_WORDS array. It turns out that --pretty and = are considered two separate words in bash4, but considered one word in bash3. Is this intended? I know I'm reporting this on patch level 33, but I've seen it on patch level 35 too. Repeat-By: 1) Install git's completion script (in contrib/completion of http://kernel.org/pub/software/scm/git/git-1.6.5.6.tar.gz) 2) Try to complete git show --pretty= and you get a list of filenames instead of a list of pretty formats.
[bash-4.0 executes command without newline]
Configuration Information [Automatically generated, do not change]: Machine: sparc OS: solaris2.11 Compiler: /ws/onnv-tools/SUNWspro/SS12/bin/c99 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc' -DCONF_OSTYPE='solaris2.11' -DCONF_MACHTYPE='sparc-sun-solaris2.11' -DCONF_VENDOR='sun' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -Xc -features=extinl,extensions -xprefetch=auto -xbuiltin=%none -xnorunpath -xcsi -xinline=%auto -xustr=ascii_utf16_ushort -xF=%none -xthreadvar=%all -xspace -xldscope=symbolic -KPIC -mt -D_REENTRANT -D__EXTENSIONS__=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=600 -D_XPG6 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_C_SOURCE=200112L -D__XOPEN_OR_POSIX -D_STRICT_STDC -D_STRICT_STDC__ -D_STDC_C99 -D_ISOC99_SOURCE -D__C99FEATURES__ -DSOLARIS -m32 -xvis=yes -xmemalign=8i -xregs=appl -xtarget=ultra2 -xarch=sparcvis -xchip=ultra2 -xO4 -s -DSHELL -DHAVE_CONFIG_H -DSOLARIS -I. -I. -I./include -I./lib -DTEXT_DOMAIN= -I/net/train/builds/arindam/6811876/sfwnv/proto/root_sparc/usr/include -I/net/train/builds/arindam/6811876/sfwnv/proto/root_sparc/usr/sfw/include -I/net/train/b! uilds/arindam/6811876/sfwnv/proto/root_sparc/usr/include-Xc -features=extinl,extensions -xprefetch=auto -xbuiltin=%none -xnorunpath -xcsi -xinline=%auto -xustr=ascii_utf16_ushort -xF=%none -xthreadvar=%all -xspace -xldscope=symbolic -KPIC -mt -D_REENTRANT -D__EXTENSIONS__=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=600 -D_XPG6 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_C_SOURCE=200112L -D__XOPEN_OR_POSIX -D_STRICT_STDC -D_STRICT_STDC__ -D_STDC_C99 -D_ISOC99_SOURCE -D__C99FEATURES__ -DSOLARIS -m32 -xvis=yes -xmemalign=8i -xregs=appl -xtarget=ultra2 -xarch=sparcvis -xchip=ultra2 -xO4 -s uname output: SunOS train 5.11 snv_125 sun4u sparc SUNW,Sun-Fire-V890 Machine Type: sparc-sun-solaris2.11 Bash Version: 4.0 Patch Level: 28 Release Status: release Description: bash executes command without newline This bug was assumed to be fixed with the intregation of bash-4.0, but it is still reproducible. Repeat-By: - login to a system - if your login shell is not bash, then enter bash shell - do 'su -' - once you are a super user, create a new user - now, su to this new user. - type 'date > /tmp/date.txt' (don't issue a carriage return) - close the gnome-terminal/dtterm window - login to the system again and ls /tmp/date.txt, and you will find that the file is created. Fix: The above problem only occurs when the parent process is running su(1M) program. So, when this process running su is sent a HUP signal from another window, then init process becomes the parent of the bash process. This is because bash belonged to an orphaned process group and was immediately parented to the init process. At this point, if the window running su program was closed, whatever characters that were accumulated in the buffer of the interactive bash program was sent for an I/O to the underlying file mapped to the stream. The problem here is that bash should check its buffer for a newline character, which is transferred by the tty driver (when it reads ). If no newline was found, then the contents of the buffer should be discarded. The problem is with readline_internal_char()/readline_internal_charloop() which calls rl_read_key to fetch a key including pending input. If the key is EOF, and length of the input line (i.e rl_end) was not 0, then this key is converted to a newline. Also rl_newline() should be called only if a newline has been detected webrev location: http://cr.opensolaris.org/~as158974/sfwnv/
Crash when completing a quoted string ending with '\'
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux pirzuine 2.6.31-16-generic #52-Ubuntu SMP Thu Dec 3 22:00:22 UTC 2009 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 4.0 Patch Level: 33 Release Status: release Description: Bash crashes when trying to complete a quoted string ending with '\' Repeat-By: Launch bash, type: "\ and press TAB See bash crash: $ "\ malloc: unknown:0: assertion botched free: start and end chunk sizes differ last command: X Aborting...Aborted Fix: The problem is in bash_dequote_filename(). If the string ends with '\', then a spurious write of '\0' will happen after the end of the allocated area. This will overwrite the guard and make the free() fail. Following patch fixes it: -- bash/bashline.c 2009-12-17 02:13:36.0 +0100 +++ /tmp/bashline.c 2009-12-17 02:12:10.0 +0100 @@ -3223,9 +3223,10 @@ else if (quoted == '"' && ((sh_syntaxtab[p[1]] & CBSDQUOTE) == 0)) *r++ = *p; -*r++ = *++p; -if (*p == '\0') +if (*++p == '\0') break; + +*r++ = *p; continue; } /* Close quote. */
BASH Command substitution
Dear Chet Ramey,
I have a conversation on an other bug forum, then have been directed
to here, I cannot find any documentation, why
$ echo $(echo "'alfa beta'")
gives 'alfa beta' whith reduced space, instead of the result of the
following more logical ways:
$ echo $(echo "'alfa beta'")
the second term suggests one parameter being substituted as
""
On the other hand, having made the substitution, one should get the
$ echo 'alfa beta'
text to be interpreted.
So why the '-s are quoted and the spaces are not?
This strange behaviour should be mentioned in the bash manual.
Zoltan Mate
- The former conversation:
bash command substitution reduce double spaces in strings:
$ echo $(echo "'alfa beta'")
'alfa beta'
Reproducible: Always
Steps to Reproduce:
--- Comment #1 From SpanKY 2009-12-16 19:32:24 [reply] ---
the second isnt actually quoted which means you ran:
argv[] = {
"echo"
"'alfa"
"beta'"
}
--- Comment #2 From ZoliM 2009-12-17 09:41:08 [reply] ---
Where is emphasized the text interpreatation process in the manual?
In
$ echo $(echo "'alfa beta'")
the second term suggests one parameter being substituted as
""
On the other hand, having made the substitution, one should get the
$ echo 'alfa beta'
text to be interpreted.
So I motion to mark in the documentation at the Command substitution chapter
the proper interpretation logic.
--- Comment #3 From SpanKY 2009-12-17 10:32:32 [reply] ---
those two examples are not equivalent. your first snippet boils down to:
echo \'alfa beta\'
this bugzilla isnt a forum for teaching people how to script bash. if you want
further help, please ask on the bash mailing list, or the gentoo forums, or
some other suitable location.
Re: BASH Command substitution
On Thu, 17 Dec 2009, Zoltan Mate wrote:
> Dear Chet Ramey,
>
> I have a conversation on an other bug forum, then have been directed
> to here, I cannot find any documentation, why
>
> $ echo $(echo "'alfa beta'")
> gives 'alfa beta' whith reduced space, instead of the result of the
> following more logical ways:
>
> $ echo $(echo "'alfa beta'")
> the second term suggests one parameter being substituted as
> ""
>
> On the other hand, having made the substitution, one should get the
> $ echo 'alfa beta'
> text to be interpreted.
>
>
> So why the '-s are quoted and the spaces are not?
> This strange behaviour should be mentioned in the bash manual.
The output of the command substitution is two arguments. It you
want it intepreted as one, quote it:
echo "$(echo "'alfa beta'")"
> - The former conversation:
>
> bash command substitution reduce double spaces in strings:
>
> $ echo $(echo "'alfa beta'")
> 'alfa beta'
>
>
> Reproducible: Always
>
> Steps to Reproduce:
>
>
> --- Comment #1 From SpanKY 2009-12-16 19:32:24 [reply] ---
>
> the second isnt actually quoted which means you ran:
> argv[] = {
> "echo"
> "'alfa"
> "beta'"
> }
>
>
> --- Comment #2 From ZoliM 2009-12-17 09:41:08 [reply] ---
>
> Where is emphasized the text interpreatation process in the manual?
>
> In
> $ echo $(echo "'alfa beta'")
> the second term suggests one parameter being substituted as
> ""
>
> On the other hand, having made the substitution, one should get the
> $ echo 'alfa beta'
> text to be interpreted.
>
> So I motion to mark in the documentation at the Command substitution chapter
> the proper interpretation logic.
>
>
> --- Comment #3 From SpanKY 2009-12-17 10:32:32 [reply] ---
>
> those two examples are not equivalent. your first snippet boils down to:
> echo \'alfa beta\'
>
> this bugzilla isnt a forum for teaching people how to script bash. if you
> want
> further help, please ask on the bash mailing list, or the gentoo forums, or
> some other suitable location.
--
Chris F.A. Johnson, webmaster
===
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Re: completion considers equals sign (=) its own word?
On 12/15/09 6:01 AM, bebar...@gmail.com wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i486 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL > -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 > -Wall > uname output: Linux swboyd-laptop 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 > 04:01:29 UTC 2009 i686 GNU/Linux > Machine Type: i486-pc-linux-gnu > > Bash Version: 4.0 > Patch Level: 33 > Release Status: release > > Description: > When completing options for git I used to be able to get a list > of pretty formats by completing the --pretty= option. The option > ends in an equals sign, so the completion looks for the word > --pretty= in the COMP_WORDS array. It turns out that --pretty and = > are considered two separate words in bash4, but considered one word > in bash3. Is this intended? Yes. The programmable completion in bash-4.x uses the same set of characters to split words as the readline word completion code. Doing otherwise led to too many weird inconsistencies. If you want to remove `=' from the set of `completion word break' characters, you can modify the COMP_WORDBREAKS variable. 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-4.0 executes command without newline]
On 12/16/09 7:59 AM, Arindam Sarkar - Sun Microsystems wrote: > Configuration Information [Automatically generated, do not change]: > Machine: sparc > OS: solaris2.11 > Compiler: /ws/onnv-tools/SUNWspro/SS12/bin/c99 > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc' > -DCONF_OSTYPE='solaris2.11' -DCONF_MACHTYPE='sparc-sun-solaris2.11' > -DCONF_VENDOR='sun' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -Xc > -features=extinl,extensions -xprefetch=auto -xbuiltin=%none -xnorunpath > -xcsi -xinline=%auto -xustr=ascii_utf16_ushort -xF=%none > -xthreadvar=%all -xspace -xldscope=symbolic -KPIC -mt -D_REENTRANT > -D__EXTENSIONS__=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > -D_XOPEN_SOURCE=600 -D_XPG6 -D_POSIX_PTHREAD_SEMANTICS > -D_POSIX_C_SOURCE=200112L -D__XOPEN_OR_POSIX -D_STRICT_STDC > -D_STRICT_STDC__ -D_STDC_C99 -D_ISOC99_SOURCE -D__C99FEATURES__ > -DSOLARIS -m32 -xvis=yes -xmemalign=8i -xregs=appl -xtarget=ultra2 > -xarch=sparcvis -xchip=ultra2 -xO4 -s -DSHELL -DHAVE_CONFIG_H > -DSOLARIS -I. -I. -I./include -I./lib -DTEXT_DOMAIN= > -I/net/train/builds/arindam/6811876/sfwnv/proto/root_sparc/usr/include > -I/net/train/builds/arindam/6811876/sfwnv/proto/root_sparc/usr/sfw/include > -I/net/train/b! > uilds/arindam/6811876/sfwnv/proto/root_sparc/usr/include-Xc > -features=extinl,extensions -xprefetch=auto -xbuiltin=%none -xnorunpath > -xcsi -xinline=%auto -xustr=ascii_utf16_ushort -xF=%none > -xthreadvar=%all -xspace -xldscope=symbolic -KPIC -mt -D_REENTRANT > -D__EXTENSIONS__=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > -D_XOPEN_SOURCE=600 -D_XPG6 -D_POSIX_PTHREAD_SEMANTICS > -D_POSIX_C_SOURCE=200112L -D__XOPEN_OR_POSIX -D_STRICT_STDC > -D_STRICT_STDC__ -D_STDC_C99 -D_ISOC99_SOURCE -D__C99FEATURES__ > -DSOLARIS -m32 -xvis=yes -xmemalign=8i -xregs=appl -xtarget=ultra2 > -xarch=sparcvis -xchip=ultra2 -xO4 -s > uname output: SunOS train 5.11 snv_125 sun4u sparc SUNW,Sun-Fire-V890 > Machine Type: sparc-sun-solaris2.11 > > Bash Version: 4.0 > Patch Level: 28 > Release Status: release > > Description: >bash executes command without newline >This bug was assumed to be fixed with the intregation >of bash-4.0, but it is still reproducible. This is not a bug. Shells dating back to v7 have interpreted EOF as a token delimiter equivalent to newline. Posix standardizes this behavior. 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: Crash when completing a quoted string ending with '\'
On 12/16/09 8:28 PM, benoit.boissi...@ens-lyon.org wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i486 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL > -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 > -Wall > uname output: Linux pirzuine 2.6.31-16-generic #52-Ubuntu SMP Thu Dec 3 > 22:00:22 UTC 2009 i686 GNU/Linux > Machine Type: i486-pc-linux-gnu > > Bash Version: 4.0 > Patch Level: 33 > Release Status: release > > Description: > Bash crashes when trying to complete a quoted string ending with '\' Thanks for the report. This has already been fixed for bash-4.1. 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 Command substitution
On Thu, 17 Dec 2009 12:02:35 +0100 Zoltan Mate articulated: > this bugzilla isnt a forum for teaching people how to script bash. > if you want further help, please ask on the bash mailing list, or the > gentoo forums, or some other suitable location. Where exactly is the "bash mailing list"? -- Gerard ger...@seibercom.net |=== |=== |=== |=== | Against stupidity the very gods Themselves contend in vain. Friedrich von Schiller, "The Maid of Orleans", III, 6
Re: BASH Command substitution
On 12/17/09 6:02 AM, Zoltan Mate wrote: > Dear Chet Ramey, > > I have a conversation on an other bug forum, then have been directed > to here, I cannot find any documentation, why You have to read the section on word splitting. The output of command substitution is subject to word splitting, unless the substitution is quoted. > $ echo $(echo "'alfa beta'") > gives 'alfa beta' whith reduced space, instead of the result of the > following more logical ways: > > $ echo $(echo "'alfa beta'") > the second term suggests one parameter being substituted as > "" It helps to think about the output of each step in the word expansion process and how that feeds the next step. The command executed in a subshell is echo "'alpha beta'" The output is 'alpha beta' which is read by the calling shell as the results of the command substitution. The command substitution code removes the trailing newline and passes the 'alpha beta' to the word splitting step. Since that word is not quoted, it is subject to word splitting. The splitting results in two words: "'alpha" and "beta'". Those two words are passed to echo as separate arguments. echo outputs its arguments separated by spaces and ends with a newline. There is a program in the bash distribution named `recho' that makes it clearer. When I run recho $(echo "'alpha beta'") I get the following: argv[1] = <'alpha> argv[2] = 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/
