Re: [Bashburn-info] Nick, I'm reverting the change you made to configfunc.sh

[Nick W. <ni...@li...>]

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