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 + : '

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 d

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

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 y

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 "${ar

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 fou

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 fol

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 o

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 bo

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) 20

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