Re: Trouble with 'o' in bash
Joyce Cheng wrote: Hi all, I am experiencing trouble with the character 'o' in bash-4.0 after a recompilation. It refuses to show up both when I type it, and when I paste in something with o's. However, I am able to get some o's with the completion feature of Bash. I know for a fact that the key itself is not malfunctioning, as it works fine in vim. I've tried recompiling it several times, even with a new readline, but to no avril. You've probably rebound `o' to something besides `self-insert'. Run `bind -p' and see what it reports for `o'. When you want to rebind it, you'll probably be able to insert it by preceding it with control-V, the default binding for `literal-next'. -- ``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 3.2.39 -- race condition
Douglas Moyes wrote:
I nearly brought down a server today.
# alias d=perl-script
# d() {
# perl-script $1 |grep something|cut -d ' ' -f 3
# }
# d something
. . CRASH
turns out bash went into a loop calling d over and over again, which
resulted in thousands of grep, bash, and -d processes being executed. It
wasn't pretty.
You defined `perl-script' as a recursive function (alias expansion is
performed when a function is defined) and called it. I'm not surprised
at the result.
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/
Array parameter expansion with non-space-IFS on bash-3/4
I noticed different behaviour between bash-3 and bash-4 when
performing parameter expansion on an array with IFS set to a non-space
value. For example, on bash-3.2.39, I get:
$ bash -c 'IFS=:; printf %s\n ${@/q}' x a b
a b
Whereas on bash-4.0.33, I get:
$ bash -c 'IFS=:; printf %s\n ${@/q}' x a b
a
b
Bash-4 seems to give the desired result (leave the array intact), but
it's a bug on bash-3?
Regards,
Freddy Vulto
http://fvue.nl
Use of pipe in $( filename | program) returns null
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables uname output: Linux saturn.syslang.net 2.6.27.30-170.2.82.fc10.i686.PAE #1 SMP Mon Aug 17 08:24:23 EDT 2009 i686 athlon i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 3.2 Patch Level: 39 Release Status: release Description: use of $( filename | program) does not work. It either should or it should be properly documented. The problem also happens on bash4. Repeat-By: qq=$( /etc/passwd | grep sys) echo $qq # result is null Fix: Either fix the docs to tell people that a pipe is not allowed or fix the code to allow it.
