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

[Steven W. O. <st...@sy...>]

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