Re: incorrect brace expansion when using default values

On 9/6/06, Chris F.A. Johnson <[EMAIL PROTECTED]> wrote: On 2006-09-06, Andreas Schwab wrote: > [EMAIL PROTECTED] (Paul Jarc) writes: > >> Mike Frysinger <[EMAIL PROTECTED]> wrote: >>> this little bit of code doesnt work right: >>> foo() { echo "${1:-a{b,c}}" ; } The first '}' is interpreted

Re: completion inconsistencies involving symlinks

"Kartik K. Agaram" <[EMAIL PROTECTED]> wrote: > I conclude that the 'logical path' is maintained only by the shell, not in > the filesystem. If I'm right, then the whole notion of logical path is a > leaky abstraction honored only by 'cd -L' (are there any others?). I would > really like to

1 error detected in the compilation of "y.tab.c"

Dear Gentle people. After ./configure, then issued make, I got the following compile error: *** * * * GNU bash, version 3.1.0(3)-release (ia64-hp-hpux11.23)

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

Configuration Information [Automatically generated, do not change]: Machine: powerpc OS: darwin8.7.0 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc' - DCONF_OSTYPE='darwin8.7.0' -DCONF_MACHTYPE='powerpc-apple- darwin8.7.0' -DCONF_VENDOR='apple' -DLOCALEDIR='/usr/loc

hardwired DEBUGGER_START_FILE points to wrong location

Currently if the environmental variable is not set then DEBUGGER_START_FILE defaults to this; configure.in: DEBUGGER_START_FILE= ${ac_default_prefix}/lib/bashdb/bashdb-main.inc However looking at the bashdb package Makefiles I note that bashdb-main.inc will be found in $(datadir)/bashdb/, thus I

Re: incorrect brace expansion when using default values

On 2006-09-06, Andreas Schwab wrote: > [EMAIL PROTECTED] (Paul Jarc) writes: > >> Mike Frysinger <[EMAIL PROTECTED]> wrote: >>> this little bit of code doesnt work right: >>> foo() { echo "${1:-a{b,c}}" ; } The first '}' is interpreted as the end of the parameter expansion. >> >> Brace expansi

completion inconsistencies if cwd contains symlinks

[Resending for third time.] 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='/

The removal fails if the first number é precede d from one zero not meaningful one.

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' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux nerone 2.4.20-42.7.legacysmp #1 S

possible history bug?

discovered something interesting while using the bash shell. It seems to work with tcsh so perhaps its not a bash bug at all.. anyway.. the "history" service will not pick up commands which have a few spaces placed in front of them. eg: torproxy:~ # history | tail -5 63 cd 64 ls 65

completion inconsistencies if cwd contains symlinks

[manually resending after bashbug seems to have failed to send.] 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

Problems with bash+cygwin and longjmp

Hi! We have a very strange and non-repeatable bug in bash came with the last version of cygwin. It appears during execution of a set of long-play scripts. These scripts do a lot of work and their normal execution time is 20-40 hours. Sometimes after 20 or more hours of work bash exits as it was ki

make bash use authentication type?

In a recet discussion about ssh, the ida was put forth to get opnssh to export a variable that defines the authentication method used. The idea being to limit access to su use to only those authenticating through a public / privat key pairing. is there any way currently to configure bash to use th

possibly a bash build problem?

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 -L./lib/readline -L./lib/glob -L./lib/tilde -

completion hosed by :

Version: 3.1. If user enters unescaped `:' in command line so that the word already input constitutes prefix of some existing file names, and invokes `complete' (), what happens can not even be interpreted as provision for colon separated file name lists like `PATH' value. If `0:0', `0i', `0.tar'

comint: long lines truncated

`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 long input lines. This may be re

completion inconsistencies involving symlinks

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='/var/local/akkartik/akk.tmp/bas

Re: incorrect brace expansion when using default values

On Wednesday 06 September 2006 05:04, Andreas Schwab wrote: > [EMAIL PROTECTED] (Paul Jarc) writes: > > Mike Frysinger <[EMAIL PROTECTED]> wrote: > >> this little bit of code doesnt work right: > >> foo() { echo "${1:-a{b,c}}" ; } > > > > Brace expansion happens before parameter expansion (man bash

Re: incorrect brace expansion when using default values

[EMAIL PROTECTED] (Paul Jarc) writes: > Mike Frysinger <[EMAIL PROTECTED]> wrote: >> this little bit of code doesnt work right: >> foo() { echo "${1:-a{b,c}}" ; } > > Brace expansion happens before parameter expansion (man bash, > EXPANSION). Brace expansion doesn't come into play here, because t