Re: incorrect brace expansion when using default values
On 9/8/06, Alexander Elgert [EMAIL PROTECTED] wrote:
Tatavarty Kalyan schrieb am 07.09.2006 um 14:20:43 (+0800):
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 as the end of the parameter expansion.
It depends on the number of parameters, if the first or second brace is
taken. So this is very likely a Bug. ;)
That means in the case
foo a
the first brace is taken.
And in the case
foo
the second one does the termination.
Quote them, and they do expand:
$ foo() { echo ${1:-a{b,c}} ; }
$ foo
ab ac
However, there is a problem:
$ foo 1
1 1
Where is the second '1' coming from?
It seems
foo() { echo ${1:-a{b,c}} ; } expands to
foo() { echo ${1:-ab} ${1:-ac} ; }
Not exactly, it is acting like:
foo() { echo ${1:-ab} ${1:-ac} ; }
To check the first assumption, that there are two parameters to echo, use
the
call without any parameters to foo:
$ foo
ab ac
$
The show the second, apply a string with spaces:
$ foo() { echo ${1:-a{b,c}} ; }
$ foo x
x x
$
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
shouldn't it be more like:
$ foo() { echo ${1:-ab} ${1:-ac} ; }
For example,
$ foo() { echo ${1:-a{\'b,c}} ; }
$foo
a'b ac
$foo() { echo ${1:-a\'b} ${1:-ac} ; }
$foo
a'b ac
Alexander Elgert
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: improper handling of [] sequences
Please try, ls a[[:upper:]]a instead. a[:upper:]a matches 'a' followed by any one of ':','u','p','e','r' ,followed by 'a'. Thanks, Kalyan On 7/22/05, James Downs [EMAIL PROTECTED] wrote: Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-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_FILE_OFFSET_BITS=64 -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 uname output: Linux jdowns.epinions.com 2.6.11-1.27_FC3 #1 Tue May 17 20:27:37 EDT 2005 i686 i686 i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 3.0 Patch Level: 14 Release Status: release Description: bash-3.00$ ls a[:upper:]a aea apa ara aua Repeat-By: touch a number of files matching [a-z][a-zA-z][a-z] try the ls command listed above -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBC4ECyGDivo4dtEZcRAjynAJwMn4FffcJ6JlnpjF3kmd4FZyv/fgCdEJox LYLwc24C3wMfB5mtZgpo8aY= =0to9 -END PGP SIGNATURE- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: problem with $(/proc/net/route) on amd64
Though I get the same results as posted above on i686,i am not sure if this is a bash problem. On the other hand i feel there is might be some issue with the glibc read and /proc filesystem on some 2.6 kernels as i wasnt able to reproduce this on Redhat with 2.4.21-20.EL kernel.I was able to reproduce this problem on Redhat with 2.6.9-5.EL and Gentoo with 2.6.11-gentoo-r4. Changing the buffer size of lbuf array in zcatfd function (lib/sh/zcatfd.c) to anything greater than 128 makes bash print the complete contents of /proc/net/route.Bash calls the glibc read inside the zread function(in lib/sh/zread.c) called by zcatfd. Incidently,the first newline in /proc/net/route is the 128th character. When the SIZE argument to read function is 128 , glibc read is returning 0(end-of-file) after it reads the first chunk and therefore we get a truncated output. I was able to confirm this by running a small test program with libc read and /proc/net/route. Thanks, Kalyan On 7/16/05, Chet Ramey [EMAIL PROTECTED] wrote: Aron Griffis wrote: Bash Version: 3.0 Patch Level: 16 Release Status: release Description: Using bash internals to read /proc/net/route on amd64 stops reading at the end of the first line. Tested on bash-3.0-16 on Gentoo and Debian. Also tested on alpha, ia64 and x86, none of which exhibit the problem. I don't have any amd64 systems to test this on, so I'll have to rely on others' debugging. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live...Laugh...Love Chet Ramey, ITS, CWRU[EMAIL PROTECTED] http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: difference between complete -o default and -o bashdefault
I think bashdefault tries out username,hostname,command word,glob completions where as 'default' just tries out filename completions. On 7/8/05, Ian Macdonald [EMAIL PROTECTED] wrote: Hello, I can't quite work out what the difference is between -o default and -o bashdefault. One is readline-oriented and the other is not, but the effect appears to be the same for the cases that I have run through. Anyone? Ian -- Ian Macdonald | The one good thing about repeating your [EMAIL PROTECTED] | mistakes is that you know when to cringe. http://www.caliban.org/ | | | ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
