tab completion at empty prompt and vi mode

I had two quick questions; I'm working on moving from tcsh and trying to replicate a bit of functionality I've grown used to. With 'set autolist=ambiguous' in tcsh, if I'm at an empty prompt and I hit tab, it essentially does an ls on the directory. If I hit tab at an empty prompt in bash, it tr

Unicode Normalization on Mac OS X (HFS+ filesystem)

Configuration Information [Automatically generated, do not change]: Machine: i386 OS: darwin9.3.0 Compiler: /usr/bin/gcc-4.0 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' - DCONF_OSTYPE='darwin9.3.0' -DCONF_MACHTYPE='i386-apple-darwin9.3.0' - DCONF_VENDOR='apple' -DLOCALEDIR='/opt

read -d on a terminal

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='ba

patch failures/offsets through bash32-039

Hi. Here's a logfile of patch failures/offsets through bash32-039. Untar, cd, for i in patch ; patch < $i The sigs on bash-3.2.tar.gz and all the patches check out ok. Perhaps reroll the affected patches and fix any new failures/offsets introduced? Or issue patch 040 as a cumulative fix for tho

eval, apparently inconsistent behavior

#!/bin/bash a=( 1 2 3 ) b=( 4 5 6 ) x=a eval b=( [EMAIL PROTECTED] ) echo [EMAIL PROTECTED] #output: #1 2 3 x=b eval $x=( [EMAIL PROTECTED] ) #output: #./tst: line 15: syntax error near unexpected token `(' #./tst: line 15: `eval $x=( [EMAIL PROTECTED] ) '

Bash crashes on wildcards

Configuration Information [Automatically generated, do not change]: Machine: alpha OS: netbsd Compiler: cc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='alpha' -DCONF_OSTYPE='netbsd' -DCONF_MACHTYPE='alpha--netbsd' -DCONF_VENDOR='' -DLOCALEDIR='/usr/pkg/share/locale' -DPACKAGE='bash' -DS

Re: $IFS and "[EMAIL PROTECTED]:offset}"

On Fri, Jun 06, 2008 at 11:08:23AM +0200, Andreas Schwab wrote: > Stephane Chazelas <[EMAIL PROTECTED]> writes: > > > It still doesn't explain why ${@:1:1} expands to $1 and not $2 > > For positional parameters indexing starts at 1. [...] Alright sorry, that was me being confused. I thought [EMA

Re: $IFS and "[EMAIL PROTECTED]:offset}"

Stephane Chazelas <[EMAIL PROTECTED]> writes: > It still doesn't explain why ${@:1:1} expands to $1 and not $2 For positional parameters indexing starts at 1. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fin

Re: $IFS and "[EMAIL PROTECTED]:offset}"

On Thu, Jun 05, 2008 at 05:39:58PM +0100, Stephane Chazelas wrote: [...] > $ bash -c 'printf "%s\n" "${@:2}"' x 1 2 "3 4" 5 > 2 > 3 4 > 5 > $ bash -c 'IFS=a; printf "%s\n" "${@:2}"' 0 1 2 "3 4" 5 > 2 3 4 5 > > I don't understand why $IFS would have any influence here. The > behavior differs from k

Re: $IFS and "[EMAIL PROTECTED]:offset}"

On Fri, Jun 06, 2008 at 10:38:41AM +0200, Andreas Schwab wrote: > Stephane Chazelas <[EMAIL PROTECTED]> writes: > > > The behavior is the same in ksh, but in ksh ${@:0:1} expands to > > $0 which makes it more understandable ($0 has its meaning in > > functions as well in ksh which makes it somehow

Re: $IFS and "[EMAIL PROTECTED]:offset}"

Stephane Chazelas <[EMAIL PROTECTED]> writes: > The behavior is the same in ksh, but in ksh ${@:0:1} expands to > $0 which makes it more understandable ($0 has its meaning in > functions as well in ksh which makes it somehow consistent). > > In bash, ${@:0:1} and ${@:1:1} expand to the same thing