Thread: [Bashburn-info] Nick, I'm reverting the change you made to configfunc.sh
Brought to you by:
bashburn
From: Steven W. O. <st...@sy...> - 2008-09-29 16:55:51
|
(( ${!BB_CONFIG_VAR} == 0 )) && return 1 This is correct. BB_CONFIG_VAR is either equal to BB_CONFIG_MODIFIED or BB_ADVANCED_CONFIG_MODIFIED. So what I'm doing is to test to see if the correct variable is set to 1 or 0. You can't test to see if it's true unless you set it equal to the string 'true'. Also, if you really meant the return value of the true program then that's something else entirely. -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net |
From: Nick W. <ni...@li...> - 2008-09-29 17:07:39
|
On Mon, 29 Sep 2008 12:55:32 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > (( ${!BB_CONFIG_VAR} == 0 )) && return 1 > > This is correct. BB_CONFIG_VAR is either equal to BB_CONFIG_MODIFIED > or BB_ADVANCED_CONFIG_MODIFIED. So what I'm doing is to test to see > if the correct variable is set to 1 or 0. > > You can't test to see if it's true unless you set it equal to the > string 'true'. Also, if you really meant the return value of the true > program then that's something else entirely. > Well, if I go to the config menu, I get this if I exit ~ without/or with ~ changing anything: /usr/lib/Bashburn/lib/func/configfunc.sh: line 32: ((: == 0 : syntax error: operand expected (error token is "== 0 ") If I set it to read ${BB_CONFIG_VAR} == true all works and functions correctly. Surely in bash, a $VAR that == 0 is TRUE, == 1 is FALSE (I am teaching you to suck eggs here ;-) ). Nick -- Free Software Foundation Associate Member 5508 |
From: Steven W. O. <st...@sy...> - 2008-09-29 17:21:57
|
On Monday, Sep 29th 2008 at 13:07 -0000, quoth Nick Warne: =>On Mon, 29 Sep 2008 12:55:32 -0400 (EDT) =>"Steven W. Orr" <st...@sy...> wrote: => =>> (( ${!BB_CONFIG_VAR} == 0 )) && return 1 =>> =>> This is correct. BB_CONFIG_VAR is either equal to BB_CONFIG_MODIFIED =>> or BB_ADVANCED_CONFIG_MODIFIED. So what I'm doing is to test to see =>> if the correct variable is set to 1 or 0. =>> =>> You can't test to see if it's true unless you set it equal to the =>> string 'true'. Also, if you really meant the return value of the true =>> program then that's something else entirely. =>> => =>Well, if I go to the config menu, I get this if I exit ~ without/or with =>~ changing anything: => =>/usr/lib/Bashburn/lib/func/configfunc.sh: line 32: ((: == 0 : syntax =>error: operand expected (error token is "== 0 ") => =>If I set it to read => =>${BB_CONFIG_VAR} == true => =>all works and functions correctly. => =>Surely in bash, a $VAR that == 0 is TRUE, == 1 is FALSE (I am teaching =>you to suck eggs here ;-) ). I need more info. I'm not getting a syntax error. Just so you know what's happening, (( ${!BB_CONFIG_VAR} == 0 )) && return 1 says, "Indirect through BB_CONFIG_VAR and see if it's value is 0. BB_CONFIG_VAR is only ever equal to either BB_CONFIG_MODIFIED or BB_ADVANCED_CONFIG_MODIFIED. Both of those variables are declared to be of type integer using typeset -i typeset -i BB_CONFIG_MODIFIED=0 typeset -i BB_ADVANCED_CONFIG_MODIFIED=0 So, if you test (( ${BB_CONFIG_VAR} == 0 )) it will always be false. And if you test to see if it's equal to 'true' then that's a problem also because you're testing it inside an arithmetic test, i.e. (( )) instead of [[ ]]. Because bash does not require integer variables to be preceeded by a dollarsign in an arithmetic context, it should complain that there is no variable called true but instead it just converts the true to a 1 because it's not equal to 0. Something is going on where you might have (for some reason I don't know about) a value for BB_CONFIG_VAR of null (""). I need to see more about why you're getting a syntax problem. -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net |
From: Nick W. <ni...@li...> - 2008-09-29 17:26:01
|
On Mon, 29 Sep 2008 13:21:47 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > Just so you know what's happening, > > (( ${!BB_CONFIG_VAR} == 0 )) && return 1 > > says, "Indirect through BB_CONFIG_VAR and see if it's value is 0. > BB_CONFIG_VAR is only ever equal to either BB_CONFIG_MODIFIED or > BB_ADVANCED_CONFIG_MODIFIED. Both of those variables are declared to > be of type integer using typeset -i > > typeset -i BB_CONFIG_MODIFIED=0 > typeset -i BB_ADVANCED_CONFIG_MODIFIED=0 > > So, if you test (( ${BB_CONFIG_VAR} == 0 )) it will always be false. > And if you test to see if it's equal to 'true' then that's a problem > also because you're testing it inside an arithmetic test, i.e. (( )) > instead of [[ ]]. Because bash does not require integer variables to > be preceeded by a dollarsign in an arithmetic context, it should > complain that there is no variable called true but instead it just > converts the true to a 1 because it's not equal to 0. > > Something is going on where you might have (for some reason I don't > know about) a value for BB_CONFIG_VAR of null (""). > > I need to see more about why you're getting a syntax problem. > > Attached in script output. Nick -- Free Software Foundation Associate Member 5508 |
From: Nick W. <ni...@li...> - 2008-09-29 17:29:21
|
On Mon, 29 Sep 2008 18:25:56 +0100 Nick Warne <ni...@li...> wrote: > On Mon, 29 Sep 2008 13:21:47 -0400 (EDT) > "Steven W. Orr" <st...@sy...> wrote: > > > Just so you know what's happening, > > > > (( ${!BB_CONFIG_VAR} == 0 )) && return 1 > > > > says, "Indirect through BB_CONFIG_VAR and see if it's value is 0. > > BB_CONFIG_VAR is only ever equal to either BB_CONFIG_MODIFIED or > > BB_ADVANCED_CONFIG_MODIFIED. Both of those variables are declared > > to be of type integer using typeset -i > > > > typeset -i BB_CONFIG_MODIFIED=0 > > typeset -i BB_ADVANCED_CONFIG_MODIFIED=0 > > > > So, if you test (( ${BB_CONFIG_VAR} == 0 )) it will always be > > false. And if you test to see if it's equal to 'true' then that's a > > problem also because you're testing it inside an arithmetic test, > > i.e. (( )) instead of [[ ]]. Because bash does not require integer > > variables to be preceeded by a dollarsign in an arithmetic context, > > it should complain that there is no variable called true but > > instead it just converts the true to a 1 because it's not equal to > > 0. > > > > Something is going on where you might have (for some reason I don't > > know about) a value for BB_CONFIG_VAR of null (""). > > > > I need to see more about why you're getting a syntax problem. > > > > > > Attached in script output. Ummm. WTF. Bloody thing got stripped of the mail - let me gzip it. Nick -- Free Software Foundation Associate Member 5508 |
From: Steven W. O. <st...@sy...> - 2008-09-29 17:38:22
|
On Monday, Sep 29th 2008 at 13:29 -0000, quoth Nick Warne: =>On Mon, 29 Sep 2008 18:25:56 +0100 =>Nick Warne <ni...@li...> wrote: => =>> On Mon, 29 Sep 2008 13:21:47 -0400 (EDT) =>> "Steven W. Orr" <st...@sy...> wrote: =>> =>> > Just so you know what's happening, =>> > =>> > (( ${!BB_CONFIG_VAR} == 0 )) && return 1 =>> > =>> > says, "Indirect through BB_CONFIG_VAR and see if it's value is 0. =>> > BB_CONFIG_VAR is only ever equal to either BB_CONFIG_MODIFIED or =>> > BB_ADVANCED_CONFIG_MODIFIED. Both of those variables are declared =>> > to be of type integer using typeset -i =>> > =>> > typeset -i BB_CONFIG_MODIFIED=0 =>> > typeset -i BB_ADVANCED_CONFIG_MODIFIED=0 =>> > =>> > So, if you test (( ${BB_CONFIG_VAR} == 0 )) it will always be =>> > false. And if you test to see if it's equal to 'true' then that's a =>> > problem also because you're testing it inside an arithmetic test, =>> > i.e. (( )) instead of [[ ]]. Because bash does not require integer =>> > variables to be preceeded by a dollarsign in an arithmetic context, =>> > it should complain that there is no variable called true but =>> > instead it just converts the true to a 1 because it's not equal to =>> > 0. =>> > =>> > Something is going on where you might have (for some reason I don't =>> > know about) a value for BB_CONFIG_VAR of null (""). =>> > =>> > I need to see more about why you're getting a syntax problem. =>> > =>> > =>> =>> Attached in script output. => =>Ummm. WTF. Bloody thing got stripped of the mail - let me gzip it. I just checked in a change. Tell me if it fixes it for you. Also, what rev of bash are you running? -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steven W. Orr |
From: Nick W. <ni...@li...> - 2008-09-29 17:41:35
|
On Mon, 29 Sep 2008 13:38:13 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > On Monday, Sep 29th 2008 at 13:29 -0000, quoth Nick Warne: > > =>On Mon, 29 Sep 2008 18:25:56 +0100 > =>Nick Warne <ni...@li...> wrote: > => > =>> On Mon, 29 Sep 2008 13:21:47 -0400 (EDT) > =>> "Steven W. Orr" <st...@sy...> wrote: > =>> > =>> > Just so you know what's happening, > =>> > > =>> > (( ${!BB_CONFIG_VAR} == 0 )) && return 1 > =>> > > =>> > says, "Indirect through BB_CONFIG_VAR and see if it's value is > 0. =>> > BB_CONFIG_VAR is only ever equal to either > BB_CONFIG_MODIFIED or =>> > BB_ADVANCED_CONFIG_MODIFIED. Both of > those variables are declared =>> > to be of type integer using > typeset -i =>> > > =>> > typeset -i BB_CONFIG_MODIFIED=0 > =>> > typeset -i BB_ADVANCED_CONFIG_MODIFIED=0 > =>> > > =>> > So, if you test (( ${BB_CONFIG_VAR} == 0 )) it will always be > =>> > false. And if you test to see if it's equal to 'true' then > that's a =>> > problem also because you're testing it inside an > arithmetic test, =>> > i.e. (( )) instead of [[ ]]. Because bash does > not require integer =>> > variables to be preceeded by a dollarsign > in an arithmetic context, =>> > it should complain that there is no > variable called true but =>> > instead it just converts the true to a > 1 because it's not equal to =>> > 0. > =>> > > =>> > Something is going on where you might have (for some reason I > don't =>> > know about) a value for BB_CONFIG_VAR of null (""). > =>> > > =>> > I need to see more about why you're getting a syntax problem. > =>> > > =>> > > =>> > =>> Attached in script output. > => > =>Ummm. WTF. Bloody thing got stripped of the mail - let me gzip it. > > I just checked in a change. Tell me if it fixes it for you. > > Also, what rev of bash are you running? > Nope, same issue. GNU bash, version 3.1.17(2)-release (i486-slackware-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. Nick -- Free Software Foundation Associate Member 5508 |
From: Steven W. O. <st...@sy...> - 2008-09-29 17:53:21
|
On Monday, Sep 29th 2008 at 13:41 -0000, quoth Nick Warne: =>On Mon, 29 Sep 2008 13:38:13 -0400 (EDT) =>"Steven W. Orr" <st...@sy...> wrote: => =>> On Monday, Sep 29th 2008 at 13:29 -0000, quoth Nick Warne: =>> =>> =>On Mon, 29 Sep 2008 18:25:56 +0100 =>> =>Nick Warne <ni...@li...> wrote: =>> => =>> =>> On Mon, 29 Sep 2008 13:21:47 -0400 (EDT) =>> =>> "Steven W. Orr" <st...@sy...> wrote: =>> =>> =>> =>> > Just so you know what's happening, =>> =>> > =>> =>> > (( ${!BB_CONFIG_VAR} == 0 )) && return 1 =>> =>> > =>> =>> > says, "Indirect through BB_CONFIG_VAR and see if it's value is =>> 0. =>> > BB_CONFIG_VAR is only ever equal to either =>> BB_CONFIG_MODIFIED or =>> > BB_ADVANCED_CONFIG_MODIFIED. Both of =>> those variables are declared =>> > to be of type integer using =>> typeset -i =>> > =>> =>> > typeset -i BB_CONFIG_MODIFIED=0 =>> =>> > typeset -i BB_ADVANCED_CONFIG_MODIFIED=0 =>> =>> > =>> =>> > So, if you test (( ${BB_CONFIG_VAR} == 0 )) it will always be =>> =>> > false. And if you test to see if it's equal to 'true' then =>> that's a =>> > problem also because you're testing it inside an =>> arithmetic test, =>> > i.e. (( )) instead of [[ ]]. Because bash does =>> not require integer =>> > variables to be preceeded by a dollarsign =>> in an arithmetic context, =>> > it should complain that there is no =>> variable called true but =>> > instead it just converts the true to a =>> 1 because it's not equal to =>> > 0. =>> =>> > =>> =>> > Something is going on where you might have (for some reason I =>> don't =>> > know about) a value for BB_CONFIG_VAR of null (""). =>> =>> > =>> =>> > I need to see more about why you're getting a syntax problem. =>> =>> > =>> =>> > =>> =>> =>> =>> Attached in script output. =>> => =>> =>Ummm. WTF. Bloody thing got stripped of the mail - let me gzip it. =>> =>> I just checked in a change. Tell me if it fixes it for you. =>> =>> Also, what rev of bash are you running? =>> =>Nope, same issue. => =>GNU bash, version 3.1.17(2)-release (i486-slackware-linux-gnu) =>Copyright (C) 2005 Free Software Foundation, Inc. Don't know what to say. Can you start putting print statements in? When you go into bbconfmenu, BB_CONFIG_VAR *has* to be one or the other. You can see it being set in configure and advanced. -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steven W. Orr |
From: Nick W. <ni...@li...> - 2008-09-29 18:00:58
|
On Mon, 29 Sep 2008 13:53:12 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > On Monday, Sep 29th 2008 at 13:41 -0000, quoth Nick Warne: > > =>On Mon, 29 Sep 2008 13:38:13 -0400 (EDT) > =>"Steven W. Orr" <st...@sy...> wrote: > => > =>> On Monday, Sep 29th 2008 at 13:29 -0000, quoth Nick Warne: > =>> > =>> =>On Mon, 29 Sep 2008 18:25:56 +0100 > =>> =>Nick Warne <ni...@li...> wrote: > =>> => > =>> =>> On Mon, 29 Sep 2008 13:21:47 -0400 (EDT) > =>> =>> "Steven W. Orr" <st...@sy...> wrote: > =>> =>> > =>> =>> > Just so you know what's happening, > =>> =>> > > =>> =>> > (( ${!BB_CONFIG_VAR} == 0 )) && return 1 > =>> =>> > > =>> =>> > says, "Indirect through BB_CONFIG_VAR and see if it's value > is =>> 0. =>> > BB_CONFIG_VAR is only ever equal to either > =>> BB_CONFIG_MODIFIED or =>> > BB_ADVANCED_CONFIG_MODIFIED. Both of > =>> those variables are declared =>> > to be of type integer using > =>> typeset -i =>> > > =>> =>> > typeset -i BB_CONFIG_MODIFIED=0 > =>> =>> > typeset -i BB_ADVANCED_CONFIG_MODIFIED=0 > =>> =>> > > =>> =>> > So, if you test (( ${BB_CONFIG_VAR} == 0 )) it will always > be =>> =>> > false. And if you test to see if it's equal to 'true' > then =>> that's a =>> > problem also because you're testing it inside > an =>> arithmetic test, =>> > i.e. (( )) instead of [[ ]]. Because > bash does =>> not require integer =>> > variables to be preceeded by > a dollarsign =>> in an arithmetic context, =>> > it should complain > that there is no =>> variable called true but =>> > instead it just > converts the true to a =>> 1 because it's not equal to =>> > 0. > =>> =>> > > =>> =>> > Something is going on where you might have (for some reason > I =>> don't =>> > know about) a value for BB_CONFIG_VAR of null (""). > =>> =>> > > =>> =>> > I need to see more about why you're getting a syntax > problem. =>> =>> > > =>> =>> > > =>> =>> > =>> =>> Attached in script output. > =>> => > =>> =>Ummm. WTF. Bloody thing got stripped of the mail - let me > gzip it. =>> > =>> I just checked in a change. Tell me if it fixes it for you. > =>> > =>> Also, what rev of bash are you running? > =>> > =>Nope, same issue. > => > =>GNU bash, version 3.1.17(2)-release (i486-slackware-linux-gnu) > =>Copyright (C) 2005 Free Software Foundation, Inc. > > Don't know what to say. Can you start putting print statements in? > When you go into bbconfmenu, BB_CONFIG_VAR *has* to be one or the > other. > > You can see it being set in configure and advanced. > Well, you could be onto something here. Glad I am not going mad again... My changes marked <---HERE: # Confirmation routine on leaving configuration. get_confirm() { echo "$BB_CONFIG_VAR" <--------------------------------- HERE (( ${!BB_CONFIG_VAR} == 0 )) && return 1 And the output running BB: |-(Actions) |- 19) Apply changes |- 20) Apply defaults |- 21) Revert changes |- 22) Back Your Choice? |> 22 BB_CONFIG_MODIFIED <--------------- HERE /usr/lib/Bashburn/lib/func/configfunc.sh: line 33: ((: == 0 : syntax error: operand expected (error token is "== 0 ") It appears you changed an option but did not apply it. Here you can select 'n' to go back and do so; If you wish to ignore the change, select 'y'. Nick -- Free Software Foundation Associate Member 5508 |
From: Nick W. <ni...@li...> - 2008-09-29 18:40:41
|
On Mon, 29 Sep 2008 19:00:52 +0100 Nick Warne <ni...@li...> wrote: > On Mon, 29 Sep 2008 13:53:12 -0400 (EDT) > "Steven W. Orr" <st...@sy...> wrote: > > > On Monday, Sep 29th 2008 at 13:41 -0000, quoth Nick Warne: > > > > =>On Mon, 29 Sep 2008 13:38:13 -0400 (EDT) > > =>"Steven W. Orr" <st...@sy...> wrote: > > => > > =>> On Monday, Sep 29th 2008 at 13:29 -0000, quoth Nick Warne: > > =>> > > =>> =>On Mon, 29 Sep 2008 18:25:56 +0100 > > =>> =>Nick Warne <ni...@li...> wrote: > > =>> => > > =>> =>> On Mon, 29 Sep 2008 13:21:47 -0400 (EDT) > > =>> =>> "Steven W. Orr" <st...@sy...> wrote: > > =>> =>> > > =>> =>> > Just so you know what's happening, > > =>> =>> > > > =>> =>> > (( ${!BB_CONFIG_VAR} == 0 )) && return 1 > > =>> =>> > > > =>> =>> > says, "Indirect through BB_CONFIG_VAR and see if it's > > value is =>> 0. =>> > BB_CONFIG_VAR is only ever equal to either > > =>> BB_CONFIG_MODIFIED or =>> > BB_ADVANCED_CONFIG_MODIFIED. Both > > of =>> those variables are declared =>> > to be of type integer > > using =>> typeset -i =>> > > > =>> =>> > typeset -i BB_CONFIG_MODIFIED=0 > > =>> =>> > typeset -i BB_ADVANCED_CONFIG_MODIFIED=0 > > =>> =>> > > > =>> =>> > So, if you test (( ${BB_CONFIG_VAR} == 0 )) it will always > > be =>> =>> > false. And if you test to see if it's equal to 'true' > > then =>> that's a =>> > problem also because you're testing it > > inside an =>> arithmetic test, =>> > i.e. (( )) instead of [[ ]]. > > Because bash does =>> not require integer =>> > variables to be > > preceeded by a dollarsign =>> in an arithmetic context, =>> > it > > should complain that there is no =>> variable called true but =>> > > > instead it just converts the true to a =>> 1 because it's not equal > > to =>> > 0. =>> =>> > > > =>> =>> > Something is going on where you might have (for some > > reason I =>> don't =>> > know about) a value for BB_CONFIG_VAR of > > null (""). =>> =>> > > > =>> =>> > I need to see more about why you're getting a syntax > > problem. =>> =>> > > > =>> =>> > > > =>> =>> > > =>> =>> Attached in script output. > > =>> => > > =>> =>Ummm. WTF. Bloody thing got stripped of the mail - let me > > gzip it. =>> > > =>> I just checked in a change. Tell me if it fixes it for you. > > =>> > > =>> Also, what rev of bash are you running? > > =>> > > =>Nope, same issue. > > => > > =>GNU bash, version 3.1.17(2)-release (i486-slackware-linux-gnu) > > =>Copyright (C) 2005 Free Software Foundation, Inc. > > > > Don't know what to say. Can you start putting print statements in? > > When you go into bbconfmenu, BB_CONFIG_VAR *has* to be one or the > > other. > > > > You can see it being set in configure and advanced. > > > Well, you could be onto something here. Glad I am not going mad > again... > > My changes marked <---HERE: > > # Confirmation routine on leaving configuration. > get_confirm() > { > echo "$BB_CONFIG_VAR" <--------------------------------- HERE > (( ${!BB_CONFIG_VAR} == 0 )) && return 1 > > > And the output running BB: > > |-(Actions) > |- 19) Apply changes > |- 20) Apply defaults > |- 21) Revert changes > |- 22) Back > Your Choice? |> 22 > > BB_CONFIG_MODIFIED <--------------- HERE > /usr/lib/Bashburn/lib/func/configfunc.sh: line 33: ((: == 0 : syntax > error: operand expected (error token is "== 0 ") It appears you > changed an option but did not apply it. > > Here you can select 'n' to go back and do so; > If you wish to ignore the change, select 'y'. OK, I think I have your logic here. This works too (for me (tm) ) get_confirm() { (( BB_CONFIG_VAR == 0 )) && return 1 It works perfectly... I change something, that test fails so I get asked if I meant to apply changes - if I don't change anything, nothing happens and I go back to menu. Nick -- Free Software Foundation Associate Member 5508 |
From: Steven W. O. <st...@sy...> - 2008-09-29 19:25:37
|
On Monday, Sep 29th 2008 at 14:00 -0000, quoth Nick Warne: =>On Mon, 29 Sep 2008 13:53:12 -0400 (EDT) =>"Steven W. Orr" <st...@sy...> wrote: => =>> On Monday, Sep 29th 2008 at 13:41 -0000, quoth Nick Warne: =>> =>> =>On Mon, 29 Sep 2008 13:38:13 -0400 (EDT) =>> =>"Steven W. Orr" <st...@sy...> wrote: =>> => =>> =>> On Monday, Sep 29th 2008 at 13:29 -0000, quoth Nick Warne: =>> =>> =>> =>> =>On Mon, 29 Sep 2008 18:25:56 +0100 =>> =>> =>Nick Warne <ni...@li...> wrote: =>> =>> => =>> =>> =>> On Mon, 29 Sep 2008 13:21:47 -0400 (EDT) =>> =>> =>> "Steven W. Orr" <st...@sy...> wrote: =>> =>> =>> =>> =>> =>> > Just so you know what's happening, =>> =>> =>> > =>> =>> =>> > (( ${!BB_CONFIG_VAR} == 0 )) && return 1 =>> =>> =>> > =>> =>> =>> > says, "Indirect through BB_CONFIG_VAR and see if it's value =>> is =>> 0. =>> > BB_CONFIG_VAR is only ever equal to either =>> =>> BB_CONFIG_MODIFIED or =>> > BB_ADVANCED_CONFIG_MODIFIED. Both of =>> =>> those variables are declared =>> > to be of type integer using =>> =>> typeset -i =>> > =>> =>> =>> > typeset -i BB_CONFIG_MODIFIED=0 =>> =>> =>> > typeset -i BB_ADVANCED_CONFIG_MODIFIED=0 =>> =>> =>> > =>> =>> =>> > So, if you test (( ${BB_CONFIG_VAR} == 0 )) it will always =>> be =>> =>> > false. And if you test to see if it's equal to 'true' =>> then =>> that's a =>> > problem also because you're testing it inside =>> an =>> arithmetic test, =>> > i.e. (( )) instead of [[ ]]. Because =>> bash does =>> not require integer =>> > variables to be preceeded by =>> a dollarsign =>> in an arithmetic context, =>> > it should complain =>> that there is no =>> variable called true but =>> > instead it just =>> converts the true to a =>> 1 because it's not equal to =>> > 0. =>> =>> =>> > =>> =>> =>> > Something is going on where you might have (for some reason =>> I =>> don't =>> > know about) a value for BB_CONFIG_VAR of null (""). =>> =>> =>> > =>> =>> =>> > I need to see more about why you're getting a syntax =>> problem. =>> =>> > =>> =>> =>> > =>> =>> =>> =>> =>> =>> Attached in script output. =>> =>> => =>> =>> =>Ummm. WTF. Bloody thing got stripped of the mail - let me =>> gzip it. =>> =>> =>> I just checked in a change. Tell me if it fixes it for you. =>> =>> =>> =>> Also, what rev of bash are you running? =>> =>> =>> =>Nope, same issue. =>> => =>> =>GNU bash, version 3.1.17(2)-release (i486-slackware-linux-gnu) =>> =>Copyright (C) 2005 Free Software Foundation, Inc. =>> =>> Don't know what to say. Can you start putting print statements in? =>> When you go into bbconfmenu, BB_CONFIG_VAR *has* to be one or the =>> other. =>> =>> You can see it being set in configure and advanced. =>> =>Well, you could be onto something here. Glad I am not going mad =>again... => =>My changes marked <---HERE: => =># Confirmation routine on leaving configuration. =>get_confirm() =>{ =>echo "$BB_CONFIG_VAR" <--------------------------------- HERE =>(( ${!BB_CONFIG_VAR} == 0 )) && return 1 => => =>And the output running BB: => =>|-(Actions) =>|- 19) Apply changes =>|- 20) Apply defaults =>|- 21) Revert changes =>|- 22) Back =>Your Choice? |> 22 => =>BB_CONFIG_MODIFIED <--------------- HERE =>/usr/lib/Bashburn/lib/func/configfunc.sh: line 33: ((: == 0 : syntax =>error: operand expected (error token is "== 0 ") It appears you changed =>an option but did not apply it. => =>Here you can select 'n' to go back and do so; =>If you wish to ignore the change, select 'y'. This kinda sucks having to do this long distance like this. Next step might be, after your echo, to add something like echo "!BB_CONFIG_VAR = ${!BB_CONFIG_VAR}" Having said that, I have an idea.... I'm wondering if you're somehow causing the ! in ${!stuff...} to be interpreted as a history expansion character. Run this one liner for me: #! /bin/bash echo $SHELLOPTS The value printed for me is braceexpand:hashall:interactive-comments If yours is printing out something that has histexpand in it then we've found the problem. I kind of doubt it but it's worth checking. -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steven W. Orr |
From: Nick W. <ni...@li...> - 2008-09-29 19:47:09
|
On Mon, 29 Sep 2008 15:25:29 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > On Monday, Sep 29th 2008 at 14:00 -0000, quoth Nick Warne: > > =>On Mon, 29 Sep 2008 13:53:12 -0400 (EDT) > =>"Steven W. Orr" <st...@sy...> wrote: > => > =>> On Monday, Sep 29th 2008 at 13:41 -0000, quoth Nick Warne: > =>> > =>> =>On Mon, 29 Sep 2008 13:38:13 -0400 (EDT) > =>> =>"Steven W. Orr" <st...@sy...> wrote: > =>> => > =>> =>> On Monday, Sep 29th 2008 at 13:29 -0000, quoth Nick Warne: > =>> =>> > =>> =>> =>On Mon, 29 Sep 2008 18:25:56 +0100 > =>> =>> =>Nick Warne <ni...@li...> wrote: > =>> =>> => > =>> =>> =>> On Mon, 29 Sep 2008 13:21:47 -0400 (EDT) > =>> =>> =>> "Steven W. Orr" <st...@sy...> wrote: > =>> =>> =>> > =>> =>> =>> > Just so you know what's happening, > =>> =>> =>> > > =>> =>> =>> > (( ${!BB_CONFIG_VAR} == 0 )) && return 1 > =>> =>> =>> > > =>> =>> =>> > says, "Indirect through BB_CONFIG_VAR and see if it's > value =>> is =>> 0. =>> > BB_CONFIG_VAR is only ever equal to either > =>> =>> BB_CONFIG_MODIFIED or =>> > BB_ADVANCED_CONFIG_MODIFIED. > Both of =>> =>> those variables are declared =>> > to be of type > integer using =>> =>> typeset -i =>> > > =>> =>> =>> > typeset -i BB_CONFIG_MODIFIED=0 > =>> =>> =>> > typeset -i BB_ADVANCED_CONFIG_MODIFIED=0 > =>> =>> =>> > > =>> =>> =>> > So, if you test (( ${BB_CONFIG_VAR} == 0 )) it will > always =>> be =>> =>> > false. And if you test to see if it's equal > to 'true' =>> then =>> that's a =>> > problem also because you're > testing it inside =>> an =>> arithmetic test, =>> > i.e. (( )) > instead of [[ ]]. Because =>> bash does =>> not require integer =>> > > variables to be preceeded by =>> a dollarsign =>> in an arithmetic > context, =>> > it should complain =>> that there is no =>> variable > called true but =>> > instead it just =>> converts the true to a =>> > 1 because it's not equal to =>> > 0. =>> =>> =>> > > =>> =>> =>> > Something is going on where you might have (for some > reason =>> I =>> don't =>> > know about) a value for BB_CONFIG_VAR of > null (""). =>> =>> =>> > > =>> =>> =>> > I need to see more about why you're getting a syntax > =>> problem. =>> =>> > > =>> =>> =>> > > =>> =>> =>> > =>> =>> =>> Attached in script output. > =>> =>> => > =>> =>> =>Ummm. WTF. Bloody thing got stripped of the mail - let me > =>> gzip it. =>> > =>> =>> I just checked in a change. Tell me if it fixes it for you. > =>> =>> > =>> =>> Also, what rev of bash are you running? > =>> =>> > =>> =>Nope, same issue. > =>> => > =>> =>GNU bash, version 3.1.17(2)-release (i486-slackware-linux-gnu) > =>> =>Copyright (C) 2005 Free Software Foundation, Inc. > =>> > =>> Don't know what to say. Can you start putting print statements in? > =>> When you go into bbconfmenu, BB_CONFIG_VAR *has* to be one or the > =>> other. > =>> > =>> You can see it being set in configure and advanced. > =>> > =>Well, you could be onto something here. Glad I am not going mad > =>again... > => > =>My changes marked <---HERE: > => > =># Confirmation routine on leaving configuration. > =>get_confirm() > =>{ > =>echo "$BB_CONFIG_VAR" <--------------------------------- HERE > =>(( ${!BB_CONFIG_VAR} == 0 )) && return 1 > => > => > =>And the output running BB: > => > =>|-(Actions) > =>|- 19) Apply changes > =>|- 20) Apply defaults > =>|- 21) Revert changes > =>|- 22) Back > =>Your Choice? |> 22 > => > =>BB_CONFIG_MODIFIED <--------------- HERE > =>/usr/lib/Bashburn/lib/func/configfunc.sh: line 33: ((: == 0 : syntax > =>error: operand expected (error token is "== 0 ") It appears you > changed =>an option but did not apply it. > => > =>Here you can select 'n' to go back and do so; > =>If you wish to ignore the change, select 'y'. > > This kinda sucks having to do this long distance like this. > > Next step might be, after your echo, to add something like > > echo "!BB_CONFIG_VAR = ${!BB_CONFIG_VAR}" > > Having said that, I have an idea.... > > I'm wondering if you're somehow causing the ! in ${!stuff...} to be > interpreted as a history expansion character. > > Run this one liner for me: > > #! /bin/bash > echo $SHELLOPTS > > The value printed for me is > braceexpand:hashall:interactive-comments > > If yours is printing out something that has histexpand in it then > we've found the problem. I kind of doubt it but it's worth checking. > ./test braceexpand:hashall:interactive-comments The same. Now, this happened before - you sure you updated all the files Steve? You haven't got a rogue in your local that hasn't been committed yet? Nick -- Free Software Foundation Associate Member 5508 |
From: Nick W. <ni...@li...> - 2008-09-29 19:50:37
|
On Mon, 29 Sep 2008 15:25:29 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > On Monday, Sep 29th 2008 at 14:00 -0000, quoth Nick Warne: > > =>On Mon, 29 Sep 2008 13:53:12 -0400 (EDT) > =>"Steven W. Orr" <st...@sy...> wrote: > => > =>> On Monday, Sep 29th 2008 at 13:41 -0000, quoth Nick Warne: > =>> > =>> =>On Mon, 29 Sep 2008 13:38:13 -0400 (EDT) > =>> =>"Steven W. Orr" <st...@sy...> wrote: > =>> => > =>> =>> On Monday, Sep 29th 2008 at 13:29 -0000, quoth Nick Warne: > =>> =>> > =>> =>> =>On Mon, 29 Sep 2008 18:25:56 +0100 > =>> =>> =>Nick Warne <ni...@li...> wrote: > =>> =>> => > =>> =>> =>> On Mon, 29 Sep 2008 13:21:47 -0400 (EDT) > =>> =>> =>> "Steven W. Orr" <st...@sy...> wrote: > =>> =>> =>> > =>> =>> =>> > Just so you know what's happening, > =>> =>> =>> > > =>> =>> =>> > (( ${!BB_CONFIG_VAR} == 0 )) && return 1 > =>> =>> =>> > > =>> =>> =>> > says, "Indirect through BB_CONFIG_VAR and see if it's > value =>> is =>> 0. =>> > BB_CONFIG_VAR is only ever equal to either > =>> =>> BB_CONFIG_MODIFIED or =>> > BB_ADVANCED_CONFIG_MODIFIED. > Both of =>> =>> those variables are declared =>> > to be of type > integer using =>> =>> typeset -i =>> > > =>> =>> =>> > typeset -i BB_CONFIG_MODIFIED=0 > =>> =>> =>> > typeset -i BB_ADVANCED_CONFIG_MODIFIED=0 > =>> =>> =>> > > =>> =>> =>> > So, if you test (( ${BB_CONFIG_VAR} == 0 )) it will > always =>> be =>> =>> > false. And if you test to see if it's equal > to 'true' =>> then =>> that's a =>> > problem also because you're > testing it inside =>> an =>> arithmetic test, =>> > i.e. (( )) > instead of [[ ]]. Because =>> bash does =>> not require integer =>> > > variables to be preceeded by =>> a dollarsign =>> in an arithmetic > context, =>> > it should complain =>> that there is no =>> variable > called true but =>> > instead it just =>> converts the true to a =>> > 1 because it's not equal to =>> > 0. =>> =>> =>> > > =>> =>> =>> > Something is going on where you might have (for some > reason =>> I =>> don't =>> > know about) a value for BB_CONFIG_VAR of > null (""). =>> =>> =>> > > =>> =>> =>> > I need to see more about why you're getting a syntax > =>> problem. =>> =>> > > =>> =>> =>> > > =>> =>> =>> > =>> =>> =>> Attached in script output. > =>> =>> => > =>> =>> =>Ummm. WTF. Bloody thing got stripped of the mail - let me > =>> gzip it. =>> > =>> =>> I just checked in a change. Tell me if it fixes it for you. > =>> =>> > =>> =>> Also, what rev of bash are you running? > =>> =>> > =>> =>Nope, same issue. > =>> => > =>> =>GNU bash, version 3.1.17(2)-release (i486-slackware-linux-gnu) > =>> =>Copyright (C) 2005 Free Software Foundation, Inc. > =>> > =>> Don't know what to say. Can you start putting print statements in? > =>> When you go into bbconfmenu, BB_CONFIG_VAR *has* to be one or the > =>> other. > =>> > =>> You can see it being set in configure and advanced. > =>> > =>Well, you could be onto something here. Glad I am not going mad > =>again... > => > =>My changes marked <---HERE: > => > =># Confirmation routine on leaving configuration. > =>get_confirm() > =>{ > =>echo "$BB_CONFIG_VAR" <--------------------------------- HERE > =>(( ${!BB_CONFIG_VAR} == 0 )) && return 1 > => > => > =>And the output running BB: > => > =>|-(Actions) > =>|- 19) Apply changes > =>|- 20) Apply defaults > =>|- 21) Revert changes > =>|- 22) Back > =>Your Choice? |> 22 > => > =>BB_CONFIG_MODIFIED <--------------- HERE > =>/usr/lib/Bashburn/lib/func/configfunc.sh: line 33: ((: == 0 : syntax > =>error: operand expected (error token is "== 0 ") It appears you > changed =>an option but did not apply it. > => > =>Here you can select 'n' to go back and do so; > =>If you wish to ignore the change, select 'y'. > > This kinda sucks having to do this long distance like this. > > Next step might be, after your echo, to add something like > > echo "!BB_CONFIG_VAR = ${!BB_CONFIG_VAR}" Your Choice? |> 22 !BB_CONFIG_VAR = /usr/lib/Bashburn/lib/func/configfunc.sh: line 33: ((: == 0 : syntax error: operand expected (error token is "== 0 ") It appears you changed an option but did not apply it. ${!BB_CONFIG_VAR} returns sweet nothing. Nick -- Free Software Foundation Associate Member 5508 |
From: Anders L. <and...@gm...> - 2008-09-29 21:52:52
|
mån 2008-09-29 klockan 20:50 +0100 skrev Nick Warne: > On Mon, 29 Sep 2008 15:25:29 -0400 (EDT) > "Steven W. Orr" <st...@sy...> wrote: > > > On Monday, Sep 29th 2008 at 14:00 -0000, quoth Nick Warne: > > > > =>On Mon, 29 Sep 2008 13:53:12 -0400 (EDT) > > =>"Steven W. Orr" <st...@sy...> wrote: > > => > > =>> On Monday, Sep 29th 2008 at 13:41 -0000, quoth Nick Warne: > > =>> > > =>> =>On Mon, 29 Sep 2008 13:38:13 -0400 (EDT) > > =>> =>"Steven W. Orr" <st...@sy...> wrote: > > =>> => > > =>> =>> On Monday, Sep 29th 2008 at 13:29 -0000, quoth Nick Warne: > > =>> =>> > > =>> =>> =>On Mon, 29 Sep 2008 18:25:56 +0100 > > =>> =>> =>Nick Warne <ni...@li...> wrote: > > =>> =>> => > > =>> =>> =>> On Mon, 29 Sep 2008 13:21:47 -0400 (EDT) > > =>> =>> =>> "Steven W. Orr" <st...@sy...> wrote: > > =>> =>> =>> > > =>> =>> =>> > Just so you know what's happening, > > =>> =>> =>> > > > =>> =>> =>> > (( ${!BB_CONFIG_VAR} == 0 )) && return 1 > > =>> =>> =>> > > > =>> =>> =>> > says, "Indirect through BB_CONFIG_VAR and see if it's > > value =>> is =>> 0. =>> > BB_CONFIG_VAR is only ever equal to either > > =>> =>> BB_CONFIG_MODIFIED or =>> > BB_ADVANCED_CONFIG_MODIFIED. > > Both of =>> =>> those variables are declared =>> > to be of type > > integer using =>> =>> typeset -i =>> > > > =>> =>> =>> > typeset -i BB_CONFIG_MODIFIED=0 > > =>> =>> =>> > typeset -i BB_ADVANCED_CONFIG_MODIFIED=0 > > =>> =>> =>> > > > =>> =>> =>> > So, if you test (( ${BB_CONFIG_VAR} == 0 )) it will > > always =>> be =>> =>> > false. And if you test to see if it's equal > > to 'true' =>> then =>> that's a =>> > problem also because you're > > testing it inside =>> an =>> arithmetic test, =>> > i.e. (( )) > > instead of [[ ]]. Because =>> bash does =>> not require integer =>> > > > variables to be preceeded by =>> a dollarsign =>> in an arithmetic > > context, =>> > it should complain =>> that there is no =>> variable > > called true but =>> > instead it just =>> converts the true to a =>> > > 1 because it's not equal to =>> > 0. =>> =>> =>> > > > =>> =>> =>> > Something is going on where you might have (for some > > reason =>> I =>> don't =>> > know about) a value for BB_CONFIG_VAR of > > null (""). =>> =>> =>> > > > =>> =>> =>> > I need to see more about why you're getting a syntax > > =>> problem. =>> =>> > > > =>> =>> =>> > > > =>> =>> =>> > > =>> =>> =>> Attached in script output. > > =>> =>> => > > =>> =>> =>Ummm. WTF. Bloody thing got stripped of the mail - let me > > =>> gzip it. =>> > > =>> =>> I just checked in a change. Tell me if it fixes it for you. > > =>> =>> > > =>> =>> Also, what rev of bash are you running? > > =>> =>> > > =>> =>Nope, same issue. > > =>> => > > =>> =>GNU bash, version 3.1.17(2)-release (i486-slackware-linux-gnu) > > =>> =>Copyright (C) 2005 Free Software Foundation, Inc. > > =>> > > =>> Don't know what to say. Can you start putting print statements in? > > =>> When you go into bbconfmenu, BB_CONFIG_VAR *has* to be one or the > > =>> other. > > =>> > > =>> You can see it being set in configure and advanced. > > =>> > > =>Well, you could be onto something here. Glad I am not going mad > > =>again... > > => > > =>My changes marked <---HERE: > > => > > =># Confirmation routine on leaving configuration. > > =>get_confirm() > > =>{ > > =>echo "$BB_CONFIG_VAR" <--------------------------------- HERE > > =>(( ${!BB_CONFIG_VAR} == 0 )) && return 1 > > => > > => > > =>And the output running BB: > > => > > =>|-(Actions) > > =>|- 19) Apply changes > > =>|- 20) Apply defaults > > =>|- 21) Revert changes > > =>|- 22) Back > > =>Your Choice? |> 22 > > => > > =>BB_CONFIG_MODIFIED <--------------- HERE > > =>/usr/lib/Bashburn/lib/func/configfunc.sh: line 33: ((: == 0 : syntax > > =>error: operand expected (error token is "== 0 ") It appears you > > changed =>an option but did not apply it. > > => > > =>Here you can select 'n' to go back and do so; > > =>If you wish to ignore the change, select 'y'. > > > > This kinda sucks having to do this long distance like this. > > > > Next step might be, after your echo, to add something like > > > > echo "!BB_CONFIG_VAR = ${!BB_CONFIG_VAR}" > > Your Choice? |> 22 > > !BB_CONFIG_VAR = > /usr/lib/Bashburn/lib/func/configfunc.sh: line 33: ((: == 0 : syntax > error: operand expected (error token is "== 0 ") It appears you changed > an option but did not apply it. > > ${!BB_CONFIG_VAR} returns sweet nothing. > > Nick > Get the same error here. GNU bash, version 3.2.33(1)-release (x86_64-pc-linux-gnu) > > -- Anders Lindén http://bashburn.sf.net |
From: Steven W. O. <st...@sy...> - 2008-09-29 20:16:04
|
On Monday, Sep 29th 2008 at 15:50 -0000, quoth Nick Warne: =>On Mon, 29 Sep 2008 15:25:29 -0400 (EDT) =>"Steven W. Orr" <st...@sy...> wrote: => =>> On Monday, Sep 29th 2008 at 14:00 -0000, quoth Nick Warne: =>> =>> =>On Mon, 29 Sep 2008 13:53:12 -0400 (EDT) =>> =>"Steven W. Orr" <st...@sy...> wrote: =>> => =>> =>> On Monday, Sep 29th 2008 at 13:41 -0000, quoth Nick Warne: =>> =>> =>> =>> =>On Mon, 29 Sep 2008 13:38:13 -0400 (EDT) =>> =>> =>"Steven W. Orr" <st...@sy...> wrote: =>> =>> => =>> =>> =>> On Monday, Sep 29th 2008 at 13:29 -0000, quoth Nick Warne: =>> =>> =>> =>> =>> =>> =>On Mon, 29 Sep 2008 18:25:56 +0100 =>> =>> =>> =>Nick Warne <ni...@li...> wrote: =>> =>> =>> => =>> =>> =>> =>> On Mon, 29 Sep 2008 13:21:47 -0400 (EDT) =>> =>> =>> =>> "Steven W. Orr" <st...@sy...> wrote: =>> =>> =>> =>> =>> =>> =>> =>> > Just so you know what's happening, =>> =>> =>> =>> > =>> =>> =>> =>> > (( ${!BB_CONFIG_VAR} == 0 )) && return 1 =>> =>> =>> =>> > =>> =>> =>> =>> > says, "Indirect through BB_CONFIG_VAR and see if it's =>> value =>> is =>> 0. =>> > BB_CONFIG_VAR is only ever equal to either =>> =>> =>> BB_CONFIG_MODIFIED or =>> > BB_ADVANCED_CONFIG_MODIFIED. =>> Both of =>> =>> those variables are declared =>> > to be of type =>> integer using =>> =>> typeset -i =>> > =>> =>> =>> =>> > typeset -i BB_CONFIG_MODIFIED=0 =>> =>> =>> =>> > typeset -i BB_ADVANCED_CONFIG_MODIFIED=0 =>> =>> =>> =>> > =>> =>> =>> =>> > So, if you test (( ${BB_CONFIG_VAR} == 0 )) it will =>> always =>> be =>> =>> > false. And if you test to see if it's equal =>> to 'true' =>> then =>> that's a =>> > problem also because you're =>> testing it inside =>> an =>> arithmetic test, =>> > i.e. (( )) =>> instead of [[ ]]. Because =>> bash does =>> not require integer =>> > =>> variables to be preceeded by =>> a dollarsign =>> in an arithmetic =>> context, =>> > it should complain =>> that there is no =>> variable =>> called true but =>> > instead it just =>> converts the true to a =>> =>> 1 because it's not equal to =>> > 0. =>> =>> =>> > =>> =>> =>> =>> > Something is going on where you might have (for some =>> reason =>> I =>> don't =>> > know about) a value for BB_CONFIG_VAR of =>> null (""). =>> =>> =>> > =>> =>> =>> =>> > I need to see more about why you're getting a syntax =>> =>> problem. =>> =>> > =>> =>> =>> =>> > =>> =>> =>> =>> =>> =>> =>> =>> Attached in script output. =>> =>> =>> => =>> =>> =>> =>Ummm. WTF. Bloody thing got stripped of the mail - let me =>> =>> gzip it. =>> =>> =>> =>> I just checked in a change. Tell me if it fixes it for you. =>> =>> =>> =>> =>> =>> Also, what rev of bash are you running? =>> =>> =>> =>> =>> =>Nope, same issue. =>> =>> => =>> =>> =>GNU bash, version 3.1.17(2)-release (i486-slackware-linux-gnu) =>> =>> =>Copyright (C) 2005 Free Software Foundation, Inc. =>> =>> =>> =>> Don't know what to say. Can you start putting print statements in? =>> =>> When you go into bbconfmenu, BB_CONFIG_VAR *has* to be one or the =>> =>> other. =>> =>> =>> =>> You can see it being set in configure and advanced. =>> =>> =>> =>Well, you could be onto something here. Glad I am not going mad =>> =>again... =>> => =>> =>My changes marked <---HERE: =>> => =>> =># Confirmation routine on leaving configuration. =>> =>get_confirm() =>> =>{ =>> =>echo "$BB_CONFIG_VAR" <--------------------------------- HERE =>> =>(( ${!BB_CONFIG_VAR} == 0 )) && return 1 =>> => =>> => =>> =>And the output running BB: =>> => =>> =>|-(Actions) =>> =>|- 19) Apply changes =>> =>|- 20) Apply defaults =>> =>|- 21) Revert changes =>> =>|- 22) Back =>> =>Your Choice? |> 22 =>> => =>> =>BB_CONFIG_MODIFIED <--------------- HERE =>> =>/usr/lib/Bashburn/lib/func/configfunc.sh: line 33: ((: == 0 : syntax =>> =>error: operand expected (error token is "== 0 ") It appears you =>> changed =>an option but did not apply it. =>> => =>> =>Here you can select 'n' to go back and do so; =>> =>If you wish to ignore the change, select 'y'. =>> =>> This kinda sucks having to do this long distance like this. =>> =>> Next step might be, after your echo, to add something like =>> =>> echo "!BB_CONFIG_VAR = ${!BB_CONFIG_VAR}" => =>Your Choice? |> 22 => =>!BB_CONFIG_VAR = =>/usr/lib/Bashburn/lib/func/configfunc.sh: line 33: ((: == 0 : syntax =>error: operand expected (error token is "== 0 ") It appears you changed =>an option but did not apply it. => =>${!BB_CONFIG_VAR} returns sweet nothing. => =>Nick Ok. Try now. This should do it, though I'm not sure why it failed before. Like they say in the funny papers, this time fer sher. -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steven W. Orr |
From: Nick W. <ni...@li...> - 2008-09-29 22:05:25
|
On Mon, 29 Sep 2008 16:15:54 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > On Monday, Sep 29th 2008 at 15:50 -0000, quoth Nick Warne: > > =>On Mon, 29 Sep 2008 15:25:29 -0400 (EDT) > =>"Steven W. Orr" <st...@sy...> wrote: > => > =>> On Monday, Sep 29th 2008 at 14:00 -0000, quoth Nick Warne: > =>> > =>> =>On Mon, 29 Sep 2008 13:53:12 -0400 (EDT) > =>> =>"Steven W. Orr" <st...@sy...> wrote: > =>> => > =>> =>> On Monday, Sep 29th 2008 at 13:41 -0000, quoth Nick Warne: > =>> =>> > =>> =>> =>On Mon, 29 Sep 2008 13:38:13 -0400 (EDT) > =>> =>> =>"Steven W. Orr" <st...@sy...> wrote: > =>> =>> => > =>> =>> =>> On Monday, Sep 29th 2008 at 13:29 -0000, quoth Nick Warne: > =>> =>> =>> > =>> =>> =>> =>On Mon, 29 Sep 2008 18:25:56 +0100 > =>> =>> =>> =>Nick Warne <ni...@li...> wrote: > =>> =>> =>> => > =>> =>> =>> =>> On Mon, 29 Sep 2008 13:21:47 -0400 (EDT) > =>> =>> =>> =>> "Steven W. Orr" <st...@sy...> wrote: > =>> =>> =>> =>> > =>> =>> =>> =>> > Just so you know what's happening, > =>> =>> =>> =>> > > =>> =>> =>> =>> > (( ${!BB_CONFIG_VAR} == 0 )) && return 1 > =>> =>> =>> =>> > > =>> =>> =>> =>> > says, "Indirect through BB_CONFIG_VAR and see if > it's =>> value =>> is =>> 0. =>> > BB_CONFIG_VAR is only ever equal > to either =>> =>> =>> BB_CONFIG_MODIFIED or =>> > > BB_ADVANCED_CONFIG_MODIFIED. =>> Both of =>> =>> those variables are > declared =>> > to be of type =>> integer using =>> =>> typeset -i =>> > > =>> =>> =>> =>> > typeset -i BB_CONFIG_MODIFIED=0 > =>> =>> =>> =>> > typeset -i BB_ADVANCED_CONFIG_MODIFIED=0 > =>> =>> =>> =>> > > =>> =>> =>> =>> > So, if you test (( ${BB_CONFIG_VAR} == 0 )) it will > =>> always =>> be =>> =>> > false. And if you test to see if it's > equal =>> to 'true' =>> then =>> that's a =>> > problem also because > you're =>> testing it inside =>> an =>> arithmetic test, =>> > i.e. > (( )) =>> instead of [[ ]]. Because =>> bash does =>> not require > integer =>> > =>> variables to be preceeded by =>> a dollarsign =>> > in an arithmetic =>> context, =>> > it should complain =>> that there > is no =>> variable =>> called true but =>> > instead it just =>> > converts the true to a =>> =>> 1 because it's not equal to =>> > 0. > =>> =>> =>> > =>> =>> =>> =>> > Something is going on where you might > have (for some =>> reason =>> I =>> don't =>> > know about) a value > for BB_CONFIG_VAR of =>> null (""). =>> =>> =>> > > =>> =>> =>> =>> > I need to see more about why you're getting a syntax > =>> =>> problem. =>> =>> > > =>> =>> =>> =>> > > =>> =>> =>> =>> > =>> =>> =>> =>> Attached in script output. > =>> =>> =>> => > =>> =>> =>> =>Ummm. WTF. Bloody thing got stripped of the mail - > let me =>> =>> gzip it. =>> > =>> =>> =>> I just checked in a change. Tell me if it fixes it for > you. =>> =>> =>> > =>> =>> =>> Also, what rev of bash are you running? > =>> =>> =>> > =>> =>> =>Nope, same issue. > =>> =>> => > =>> =>> =>GNU bash, version 3.1.17(2)-release > (i486-slackware-linux-gnu) =>> =>> =>Copyright (C) 2005 Free Software > Foundation, Inc. =>> =>> > =>> =>> Don't know what to say. Can you start putting print > statements in? =>> =>> When you go into bbconfmenu, BB_CONFIG_VAR > *has* to be one or the =>> =>> other. > =>> =>> > =>> =>> You can see it being set in configure and advanced. > =>> =>> > =>> =>Well, you could be onto something here. Glad I am not going mad > =>> =>again... > =>> => > =>> =>My changes marked <---HERE: > =>> => > =>> =># Confirmation routine on leaving configuration. > =>> =>get_confirm() > =>> =>{ > =>> =>echo "$BB_CONFIG_VAR" <--------------------------------- HERE > =>> =>(( ${!BB_CONFIG_VAR} == 0 )) && return 1 > =>> => > =>> => > =>> =>And the output running BB: > =>> => > =>> =>|-(Actions) > =>> =>|- 19) Apply changes > =>> =>|- 20) Apply defaults > =>> =>|- 21) Revert changes > =>> =>|- 22) Back > =>> =>Your Choice? |> 22 > =>> => > =>> =>BB_CONFIG_MODIFIED <--------------- HERE > =>> =>/usr/lib/Bashburn/lib/func/configfunc.sh: line 33: ((: == 0 : > syntax =>> =>error: operand expected (error token is "== 0 ") It > appears you =>> changed =>an option but did not apply it. > =>> => > =>> =>Here you can select 'n' to go back and do so; > =>> =>If you wish to ignore the change, select 'y'. > =>> > =>> This kinda sucks having to do this long distance like this. > =>> > =>> Next step might be, after your echo, to add something like > =>> > =>> echo "!BB_CONFIG_VAR = ${!BB_CONFIG_VAR}" > => > =>Your Choice? |> 22 > => > =>!BB_CONFIG_VAR = > =>/usr/lib/Bashburn/lib/func/configfunc.sh: line 33: ((: == 0 : syntax > =>error: operand expected (error token is "== 0 ") It appears you > changed =>an option but did not apply it. > => > =>${!BB_CONFIG_VAR} returns sweet nothing. > => > =>Nick > > Ok. Try now. This should do it, though I'm not sure why it failed > before. > > Like they say in the funny papers, this time fer sher. It works! What gets me is why you do not see these issues, yet everybody does, Steve? Do you set up some sort of test environment of sorts that could hide all this sort of stuff (i.e. make it work OK)? Nick -- Free Software Foundation Associate Member 5508 |
From: Steven W. O. <st...@sy...> - 2008-09-30 02:18:36
|
On Monday, Sep 29th 2008 at 18:05 -0000, quoth Nick Warne: =>On Mon, 29 Sep 2008 16:15:54 -0400 (EDT) =>"Steven W. Orr" <st...@sy...> wrote: => =>> On Monday, Sep 29th 2008 at 15:50 -0000, quoth Nick Warne: =>> =>> =>On Mon, 29 Sep 2008 15:25:29 -0400 (EDT) =>> =>"Steven W. Orr" <st...@sy...> wrote: =>> => =>> =>> On Monday, Sep 29th 2008 at 14:00 -0000, quoth Nick Warne: =>> =>> =>> =>> =>On Mon, 29 Sep 2008 13:53:12 -0400 (EDT) =>> =>> =>"Steven W. Orr" <st...@sy...> wrote: =>> =>> => =>> =>> =>> On Monday, Sep 29th 2008 at 13:41 -0000, quoth Nick Warne: =>> =>> =>> =>> =>> =>> =>On Mon, 29 Sep 2008 13:38:13 -0400 (EDT) =>> =>> =>> =>"Steven W. Orr" <st...@sy...> wrote: =>> =>> =>> => =>> =>> =>> =>> On Monday, Sep 29th 2008 at 13:29 -0000, quoth Nick Warne: =>> =>> =>> =>> =>> =>> =>> =>> =>On Mon, 29 Sep 2008 18:25:56 +0100 =>> =>> =>> =>> =>Nick Warne <ni...@li...> wrote: =>> =>> =>> =>> => =>> =>> =>> =>> =>> On Mon, 29 Sep 2008 13:21:47 -0400 (EDT) =>> =>> =>> =>> =>> "Steven W. Orr" <st...@sy...> wrote: =>> =>> =>> =>> =>> =>> =>> =>> =>> =>> > Just so you know what's happening, =>> =>> =>> =>> =>> > =>> =>> =>> =>> =>> > (( ${!BB_CONFIG_VAR} == 0 )) && return 1 =>> =>> =>> =>> =>> > =>> =>> =>> =>> =>> > says, "Indirect through BB_CONFIG_VAR and see if =>> it's =>> value =>> is =>> 0. =>> > BB_CONFIG_VAR is only ever equal =>> to either =>> =>> =>> BB_CONFIG_MODIFIED or =>> > =>> BB_ADVANCED_CONFIG_MODIFIED. =>> Both of =>> =>> those variables are =>> declared =>> > to be of type =>> integer using =>> =>> typeset -i =>> =>> > =>> =>> =>> =>> > typeset -i BB_CONFIG_MODIFIED=0 =>> =>> =>> =>> =>> > typeset -i BB_ADVANCED_CONFIG_MODIFIED=0 =>> =>> =>> =>> =>> > =>> =>> =>> =>> =>> > So, if you test (( ${BB_CONFIG_VAR} == 0 )) it will =>> =>> always =>> be =>> =>> > false. And if you test to see if it's =>> equal =>> to 'true' =>> then =>> that's a =>> > problem also because =>> you're =>> testing it inside =>> an =>> arithmetic test, =>> > i.e. =>> (( )) =>> instead of [[ ]]. Because =>> bash does =>> not require =>> integer =>> > =>> variables to be preceeded by =>> a dollarsign =>> =>> in an arithmetic =>> context, =>> > it should complain =>> that there =>> is no =>> variable =>> called true but =>> > instead it just =>> =>> converts the true to a =>> =>> 1 because it's not equal to =>> > 0. =>> =>> =>> =>> > =>> =>> =>> =>> > Something is going on where you might =>> have (for some =>> reason =>> I =>> don't =>> > know about) a value =>> for BB_CONFIG_VAR of =>> null (""). =>> =>> =>> > =>> =>> =>> =>> =>> > I need to see more about why you're getting a syntax =>> =>> =>> problem. =>> =>> > =>> =>> =>> =>> =>> > =>> =>> =>> =>> =>> =>> =>> =>> =>> =>> Attached in script output. =>> =>> =>> =>> => =>> =>> =>> =>> =>Ummm. WTF. Bloody thing got stripped of the mail - =>> let me =>> =>> gzip it. =>> =>> =>> =>> =>> I just checked in a change. Tell me if it fixes it for =>> you. =>> =>> =>> =>> =>> =>> =>> Also, what rev of bash are you running? =>> =>> =>> =>> =>> =>> =>> =>Nope, same issue. =>> =>> =>> => =>> =>> =>> =>GNU bash, version 3.1.17(2)-release =>> (i486-slackware-linux-gnu) =>> =>> =>Copyright (C) 2005 Free Software =>> Foundation, Inc. =>> =>> =>> =>> =>> Don't know what to say. Can you start putting print =>> statements in? =>> =>> When you go into bbconfmenu, BB_CONFIG_VAR =>> *has* to be one or the =>> =>> other. =>> =>> =>> =>> =>> =>> You can see it being set in configure and advanced. =>> =>> =>> =>> =>> =>Well, you could be onto something here. Glad I am not going mad =>> =>> =>again... =>> =>> => =>> =>> =>My changes marked <---HERE: =>> =>> => =>> =>> =># Confirmation routine on leaving configuration. =>> =>> =>get_confirm() =>> =>> =>{ =>> =>> =>echo "$BB_CONFIG_VAR" <--------------------------------- HERE =>> =>> =>(( ${!BB_CONFIG_VAR} == 0 )) && return 1 =>> =>> => =>> =>> => =>> =>> =>And the output running BB: =>> =>> => =>> =>> =>|-(Actions) =>> =>> =>|- 19) Apply changes =>> =>> =>|- 20) Apply defaults =>> =>> =>|- 21) Revert changes =>> =>> =>|- 22) Back =>> =>> =>Your Choice? |> 22 =>> =>> => =>> =>> =>BB_CONFIG_MODIFIED <--------------- HERE =>> =>> =>/usr/lib/Bashburn/lib/func/configfunc.sh: line 33: ((: == 0 : =>> syntax =>> =>error: operand expected (error token is "== 0 ") It =>> appears you =>> changed =>an option but did not apply it. =>> =>> => =>> =>> =>Here you can select 'n' to go back and do so; =>> =>> =>If you wish to ignore the change, select 'y'. =>> =>> =>> =>> This kinda sucks having to do this long distance like this. =>> =>> =>> =>> Next step might be, after your echo, to add something like =>> =>> =>> =>> echo "!BB_CONFIG_VAR = ${!BB_CONFIG_VAR}" =>> => =>> =>Your Choice? |> 22 =>> => =>> =>!BB_CONFIG_VAR = =>> =>/usr/lib/Bashburn/lib/func/configfunc.sh: line 33: ((: == 0 : syntax =>> =>error: operand expected (error token is "== 0 ") It appears you =>> changed =>an option but did not apply it. =>> => =>> =>${!BB_CONFIG_VAR} returns sweet nothing. =>> => =>> =>Nick =>> =>> Ok. Try now. This should do it, though I'm not sure why it failed =>> before. =>> =>> Like they say in the funny papers, this time fer sher. => =>It works! => =>What gets me is why you do not see these issues, yet everybody does, =>Steve? => =>Do you set up some sort of test environment of sorts that could hide =>all this sort of stuff (i.e. make it work OK)? No. I always do it the same way. (as root) ./Install.sh bashburn and if I need to make sure I see any funny stuff, script bashburn exit vi typescript I'm making a couple of changes to make it even better. :-( Hold onto your hats. -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steven W. Orr |