Re: incorrect brace expansion when using default values

Chris F.A. Johnson wrote: >Quote them, and they do expand: > > $ foo() { echo "${1:-"a{b,c}"}" ; } > $ foo > ab ac Brace expansion is essentially separate from the rest of the expansions: in fact, it's designed to be part of a separate library if desired. As such, it doesn't implement all o

Re: comint: long lines truncated

Ilya N. Golubev wrote: > `comint.el' versions since revision 1.14 of 2006/05/25 02:49:47 -0 > unconditionally add `TERM=dumb' to environment of all processes they > start. Programs using readline, including bash 3.1 with their bundled > readline libraries, with this setting incorrectly truncate lo

Re: incorrect brace expansion when using default values

Tatavarty Kalyan schrieb am 08.09.2006 um 11:44:47 (+0800): > >It is because the string > > a{b,c} > >is outside of the quotes. So the brace expansion comes first and > >duplicates > >the arguments to the echo call. > > Yes, as you said the brace expansion is outside the double quotes so > s

Re: possibly a bash build problem?

George R Goffe wrote: > Howdy, > > This result (see below) seems to be redily re-creatable. Could you > take a peek at this and tell me if it is a bug or if I'm doing > something wrong please? > > Regards and thanks for your time, > > George... > > rm -f bash > gcc -L./builtins -L./lib/readline

Re: bash 3.1.17: ~/.inputrc key bindings not being read

John Purnell wrote: > > Bash Version: 3.1 > Patch Level: 17 > Release Status: release > > Description: > ~/.inputrc has the following key bindings which work correctly in > bash 2.05b: > > # Mac forward delete > "\e[3~": delete-char > > # Toggle insert/overwrite mod

Re: completion inconsistencies involving symlinks

Kartik K. Agaram 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' > -DLO

Re: read command and ascii null as delimiter

Nathan Coulter wrote: > Feature request: an option, maybe "-0" to use ascii null as the delimiter for > the "read" command. It would make the following two commands produce the > same output: > > [EMAIL PROTECTED]:~/tmp5$ printf 'hello\000there' | xargs -n1 -0 echo > hello > there > > [EMAIL P

Re: set -e vs. !

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Dan Jacobson on 9/8/2006 5:42 AM: > $ cat t.sh > set -ex > ! true #should stop here but doesn't!?! > ! false > true > false > : already quit > $ bash t.sh > + true > + false > + true > + false > $ pdksh t.sh > + true Bash is right. This

Re: set -e vs. !

Dan Jacobson <[EMAIL PROTECTED]> writes: > $ cat t.sh > set -ex > ! true #should stop here but doesn't!?! RTFM. `-e' Exit immediately if ..., unless ... the command's return status is being inverted using `!'. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] Su

set -e vs. !

$ cat t.sh set -ex ! true #should stop here but doesn't!?! ! false true false : already quit $ bash t.sh + true + false + true + false $ pdksh t.sh + true $ dash t.sh + true + false + true + false ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.