quotes invade positional parameters
WITNESS for yourselves as the quotes invade the parameters, absconding with the ones at the edges, when close enough. $ cat 201012contract #!/bin/sh -eux set a b c d e f : ''$@'' : ' '$@' ' : ''$*'' : '' $* '' : " "$* " " $ ./201012contract + set a b c d e f + : a b c d e f + : ' a' b c d e 'f ' + : 'a' b c d e 'f' + : '' a b c d e f '' + : ' a' b c d e f ' ' $ apt-show-versions bash bash/unstable uptodate 4.1-3 OK, the problem may only be -x deep, affecting the -x reporting output, but not the actual functionality, thank G.O.D.
Re: Referencing empty array with "set -u" active throws error
jens.schmid...@arcor.de wrote: For an empty "$@" this does not throw an "unbound" error, which seems to be an inconsistent behaviour to me. -u Treat unset variables as an error when substituting. I think the behaviour is consistent with the documentation. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: quotes invade positional parameters
jida...@jidanni.org wrote: $ cat 201012contract #!/bin/sh -eux set a b c d e f : ''$@'' : ' '$@' ' : ''$*'' : '' $* '' : " "$* " " $ ./201012contract + set a b c d e f + : a b c d e f + : ' a' b c d e 'f ' + : 'a' b c d e 'f' + : '' a b c d e f '' + : ' a' b c d e f ' ' $ apt-show-versions bash bash/unstable uptodate 4.1-3 OK, the problem may only be -x deep, affecting the -x reporting output, but not the actual functionality, thank G.O.D. I'd say this is expected (and by the way it's not only on set -x). -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: quotes invade positional parameters
> "JS" == Jan Schampera writes: JS> I'd say this is expected (and by the way it's not only on set -x). I see. The spaces indeed get glued to the sides. OK, see ya next time.
Re: nounset option does not work with array in arithmentic expressions
Joerg Boehmer wrote: The value of variable ar[1] is expanded to 0 although it was not set. The full syntax produces the expected behavior: The value of y is 0, since you operate in arithmetic context. This is fine. But I definitely agree it should bail out here. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Referencing empty array with "set -u" active throws error
On 12/17/10 4:48 AM, jens.schmid...@arcor.de wrote:
> Bash Version: 4.1
> Patch Level: 0
> Release Status: release
>
> Description:
>Referencing empty array with "set -u" active throws unbound variable error.
>
> Repeat-By:
> $ set -u
> $ declare -a array
> $ array=( )
> $ echo "${arr...@]}"
> bash: arr...@]: unbound variable
A variable isn't set until it's been assigned a value.
> For an empty "$@" this does not throw an "unbound" error, which seems to be
> an inconsistent behaviour to me.
Bash used to do this, but Posix declared that $@ and $* are exceptions
to the unset variable rule.
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/
Precedence of "C operators" and "bash operators"
Bash 4-1 manual indicates - "The operators and their precedence, associativity, and values are the same as in the C language" (pp. 27). - the precedence of - and + operators is different then the precedence of ! and ~. But in the book "C a reference manual" (Harbison & Steele), the four operators + - ! ~ have the same precedence. What's wrong ? Cheers, Eric -- View this message in context: http://old.nabble.com/Precedence-of-%22C-operators%22-and-%22bash-operators%22-tp30488598p30488598.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: quotes invade positional parameters
Well anyway, it would be 'no skin off of bash's back' if it just reported what it was given. If it was given ' 'a b c it should report ' 'a b c and not just 'assume' we prefer ' a' b c or ' a' 'b' 'c' etc. Just as legitimate and doesn't cause calls in the middle of the night from the old folks home. Wait, that stage of the program doesn't know it was given that, and to make it know would just increase complexity. As would reporting \ \ a b c or would it... OK, never mind.
Re: complete options not working with read -e
On 12/17/10 12:24 PM, Bill Duncan, 416-697-9315 wrote: > I'm writing a script with a command line interpreter and I can most things > working (eg. history etc.) except for one thing. The filename completion > works well for some of the commands, but I'd like to use other completion > options for others. Works well from the "real" command line, but I can't > get it to work properly in my "read -e, eval" loop.. You won't be able to do it. `read -e' uses only the readline default completions. 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/
Re: Precedence of "C operators" and "bash operators"
On 12/18/2010 09:22 AM, 12bric wrote: > > Bash 4-1 manual indicates > - "The operators and their precedence, associativity, and values are > the same as in the C language" (pp. 27). > - the precedence of - and + operators is different then the precedence > of ! and ~. > > But in the book "C a reference manual" (Harbison & Steele), the four > operators + - ! ~ have the same precedence. The unary operators + and - have the same precedence as the unary ! and ~; and that level of precedence is higher than that of the binary + and -. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Regular expressions with word boundaries no longer working in bash
On 12/17/10 12:00 PM, Harry Leitzell wrote:
> Bash Version: 4.1
> Patch Level: 5
> Release Status: release
>
> Description:
>
> Doing string matching based on word boundaries no longer works:
>
> $ bash --version
> GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu)
> Copyright (C) 2005 Free Software Foundation, Inc.
>
> $ cat test.sh
> input="foocombo foo foo bar bar foo bar some stuff foo" # the input
> expected="foocombo foo bar some stuff" # this what we expect
> for i in ${inp...@]}; do
> [[ ! ${o...@]} =~ \\b"${i}"\\b ]] && old=( ${o...@]} $i )
> done
> for i in ${inp...@]}; do
> [[ ! ${n...@]} =~ \b${i}\b ]] && new=( ${n...@]} $i )
> done
> echo "input:$input"
> echo "expected: $expected"
> echo "old code: ${old[*]}"
> echo "new code: ${new[*]}"
>
> $ bash test.sh
> input:foocombo foo foo bar bar foo bar some stuff foo
> expected: foocombo foo bar some stuff
> old code: foocombo foo bar some stuff
> new code: foocombo foo foo bar bar foo bar some stuff foo
I don't know what version of Ubuntu you're running -- I'm not sure
which various versions of bash-3.2 are on Ubuntu 8, 9, or 10 -- but
using either your "old code" pattern after setting the `compat31'
option with shopt or the following
wb='\b'
${wb}${i}${wb}
will work. This is one of the reasons the compat31 option, and the
notion of a shell compatibility level, exists. A shell variable will
usually do the job, too.
Item 33 in COMPAT and item E14 in the Bash FAQ cover the issue in
more detail.
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/
Re: Precedence of "C operators" and "bash operators"
On 12/18/10 11:22 AM, 12bric wrote: > > Bash 4-1 manual indicates > - "The operators and their precedence, associativity, and values are > the same as in the C language" (pp. 27). > - the precedence of - and + operators is different then the precedence > of ! and ~. > > But in the book "C a reference manual" (Harbison & Steele), the four > operators + - ! ~ have the same precedence. > > What's wrong ? Thanks for the report. There are indeed some problems with the treatment of unary + and - along with the ! and ~ operators. These will be fixed in the next release. 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/
