bashburn-info — BashBurn mailing list

Re: [Bashburn-info] Man page

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

On Mon, 29 Sep 2008 18:32:45 +0100
Nick Warne <ni...@li...> wrote:

> On Mon, 29 Sep 2008 13:31:17 -0400 (EDT)
> "Steven W. Orr" <st...@sy...> wrote:
> 
> > On Monday, Sep 29th 2008 at 13:22 -0000, quoth Nick Warne:
> > 
> > =>
> > =>I have been messing with a man page today - I really just gleaned
> > the =>existing docs, but I think it looks OK.
> > =>
> > =>I have attached the file - save it, then just run 'man
> > <path_to_file>'. =>
> > =>If y'all think it's OK, I will add to repository and Install
> > scripts. =>
> > =>I looked at 'man man' and presume it belongs in man(7).  It not,
> > please =>correct me, and I will fix up.
> > 
> > No, it should go into section 1.
> > Section 1. User commands
> > Section 2. System calls
> > Section 3. Runtime library calls.
> > Section 4. Special files
> > Section 5. File formats
> > Section 6. Games.
> > Section 7. Misc
> > Section 8. Admin and priviledged stuff.
> > 
> > There's no requirement (any more) for bb to be installed by root and
> > you don't have to be root to run it. It should go in section 1.
> > 
> > 
> > :-) man man gave you a description of the 'an' macro set used to
> > produce man pages. You do that by using the -m option to specify the
> > macro package you want. In this case the package is called 'an' so
> > that people would run groff -man for the purpose of confusing them.
> > 
> 
> I have built the man page OK... is anybody getting my attachments?

OK, I ask this again  - does everybody get the attachment here, or is
it the SF mailing list being clever and strips it on return to myself?

Nick
-- 
Free Software Foundation Associate Member 5508

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

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

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

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

[Anders L. <and...@gm...>]

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

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

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}"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [Bashburn-info] Man page

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

On Mon, 29 Sep 2008 13:31:17 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:

> On Monday, Sep 29th 2008 at 13:22 -0000, quoth Nick Warne:
> 
> =>
> =>I have been messing with a man page today - I really just gleaned
> the =>existing docs, but I think it looks OK.
> =>
> =>I have attached the file - save it, then just run 'man
> <path_to_file>'. =>
> =>If y'all think it's OK, I will add to repository and Install
> scripts. =>
> =>I looked at 'man man' and presume it belongs in man(7).  It not,
> please =>correct me, and I will fix up.
> 
> No, it should go into section 1.
> Section 1. User commands
> Section 2. System calls
> Section 3. Runtime library calls.
> Section 4. Special files
> Section 5. File formats
> Section 6. Games.
> Section 7. Misc
> Section 8. Admin and priviledged stuff.
> 
> There's no requirement (any more) for bb to be installed by root and
> you don't have to be root to run it. It should go in section 1.
> 
> 
> :-) man man gave you a description of the 'an' macro set used to
> produce man pages. You do that by using the -m option to specify the
> macro package you want. In this case the package is called 'an' so
> that people would run groff -man for the purpose of confusing them.
> 

I have built the man page OK... is anybody getting my attachments?

I will change it to section 1

Nick

-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] Man page

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

On Monday, Sep 29th 2008 at 13:22 -0000, quoth Nick Warne:

=>
=>I have been messing with a man page today - I really just gleaned the
=>existing docs, but I think it looks OK.
=>
=>I have attached the file - save it, then just run 'man <path_to_file>'.
=>
=>If y'all think it's OK, I will add to repository and Install scripts.
=>
=>I looked at 'man man' and presume it belongs in man(7).  It not, please
=>correct me, and I will fix up.

No, it should go into section 1.
Section 1. User commands
Section 2. System calls
Section 3. Runtime library calls.
Section 4. Special files
Section 5. File formats
Section 6. Games.
Section 7. Misc
Section 8. Admin and priviledged stuff.

There's no requirement (any more) for bb to be installed by root and you 
don't have to be root to run it. It should go in section 1.


:-) man man gave you a description of the 'an' macro set used to produce 
man pages. You do that by using the -m option to specify the macro package 
you want. In this case the package is called 'an' so that people would run 
groff -man for the purpose of confusing them.

-- 
steveo at syslang dot net TMMP1 http://frambors.syslang.net/
Do you have neighbors who are not frambors? Steven W. Orr

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

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

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

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

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

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

Re: [Bashburn-info] Install.sh options

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

On Monday, Sep 29th 2008 at 13:09 -0000, quoth Nick Warne:

=>On Mon, 29 Sep 2008 13:05:20 -0400 (EDT)
=>"Steven W. Orr" <st...@sy...> wrote:
=>
=>> =>Well, I find it a bit brain dead if a user mistypes '--prefix' as
=>> =>'-prefix' and it installs into a directory called 'refix'.
=>> =>
=>> =>BTW, SVN is back up
=>> 
=>> yabut your solution seems to imply that short options should be 
=>> constrained to uppercase (even if they *don't* take an argument).
=>> Remember that creating options is not just a question of SVR4
=>> compatibility; it's also a question of following conventions to make
=>> it more familiar.
=>> 
=>> e.g., -h == help
=>>       -v == verbose
=>>       -V == Version info
=>>       -c == alternate configfile
=>>       -d == directory spec
=>>       -i == install
=>>       -l == long output
=>>       -n == don't do it but tell me what you want to do
=>>       -o == output
=>>       -q == query status returned
=>>       -R == recurse
=>>       -t == set a type
=>>       -u == uninstall
=>> 
=>
=>OK, I understand.  But there must be a way to stop it?  Unless I am
=>messing to much.  I will have to try other install apps stuff to see :-D

I dunno. If you really hate it, I suppose we could hardwire a check in to 
see if the arg to -p is refix and reject it unless the user also adds a -f 
option (or --force) to force it. ;-)

-- 
steveo at syslang dot net TMMP1 http://frambors.syslang.net/
Do you have neighbors who are not frambors? Steven W. Orr

[Bashburn-info] Man page

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

I have been messing with a man page today - I really just gleaned the
existing docs, but I think it looks OK.

I have attached the file - save it, then just run 'man <path_to_file>'.

If y'all think it's OK, I will add to repository and Install scripts.

I looked at 'man man' and presume it belongs in man(7).  It not, please
correct me, and I will fix up.

Nick
-- 
Free Software Foundation Associate Member 5508

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

Re: [Bashburn-info] Install.sh options

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

On Mon, 29 Sep 2008 13:05:20 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:

> =>Well, I find it a bit brain dead if a user mistypes '--prefix' as
> =>'-prefix' and it installs into a directory called 'refix'.
> =>
> =>BTW, SVN is back up
> 
> yabut your solution seems to imply that short options should be 
> constrained to uppercase (even if they *don't* take an argument).
> Remember that creating options is not just a question of SVR4
> compatibility; it's also a question of following conventions to make
> it more familiar.
> 
> e.g., -h == help
>       -v == verbose
>       -V == Version info
>       -c == alternate configfile
>       -d == directory spec
>       -i == install
>       -l == long output
>       -n == don't do it but tell me what you want to do
>       -o == output
>       -q == query status returned
>       -R == recurse
>       -t == set a type
>       -u == uninstall
> 

OK, I understand.  But there must be a way to stop it?  Unless I am
messing to much.  I will have to try other install apps stuff to see :-D

Nick
-- 
Free Software Foundation Associate Member 5508

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

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

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

Re: [Bashburn-info] Install.sh options

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

On Monday, Sep 29th 2008 at 12:54 -0000, quoth Nick Warne:

=>On Mon, 29 Sep 2008 11:21:52 -0400 (EDT)
=>"Steven W. Orr" <st...@sy...> wrote:
=>
=>> On Monday, Sep 29th 2008 at 09:18 -0000, quoth Steven W. Orr:
=>> 
=>> =>On Monday, Sep 29th 2008 at 06:37 -0000, quoth Nick Warne:
=>> =>
=>> =>=>
=>> =>=>I have hardened the Install file options, after I noticed some
=>> strange =>=>behaviour with silly options (i.e. -uninstall ).
=>> =>=>
=>> =>=>There is still a big issue if you use:
=>> =>=>
=>> =>=>-prefix=/usr
=>> =>=>
=>> =>=>The install script will install into a directory called 'refix'
=>> in the =>=>current directory.
=>> =>=>
=>> =>=>Nick
=>> =>
=>> =>That should not happen. I'll look at it. :-( (after svn comes back
=>> up)
=>> 
=>> Nick, I haven't seen the change you made, but let me explain what's 
=>> happening.
=>> 
=>> The getopt/getopts calls are SVR4 compliant. That means that if you
=>> have a bunch of legal options, like a, b and c, then
=>> 
=>> foo -abc 
=>> is the same as
=>> 
=>> foo -a -b -c
=>> 
=>> In this case, we have long options. Every longopt has to have a 
=>> corresponding single letter option (to be SVR4 complient). In this
=>> case, we have -p and -u and -h. They have --prefix, --uninstall, and
=>> --help as long version.
=>> 
=>> The -p takes an argument, so if you say
=>> 
=>> Install.sh -prefix
=>> 
=>> then you get what the doctor ordered. You get -p with an option arg
=>> of refix. We probably should not be coding defensively around that.
=>> If the user was going to use the long option correctly then he would
=>> say
=>> 
=>> Install.sh --prefix dirname 
=>> or
=>> Install.sh --prefix=dirname 
=>> 
=>> But to just say -prefix is just wrong as the basis for something we
=>> should worry about.
=>> 
=>> Also note, if you say -p with no arg then that is caught as an error.
=>> 
=>> Does this help?
=>> 
=>
=>Well, I find it a bit brain dead if a user mistypes '--prefix' as
=>'-prefix' and it installs into a directory called 'refix'.
=>
=>BTW, SVN is back up

yabut your solution seems to imply that short options should be 
constrained to uppercase (even if they *don't* take an argument). Remember 
that creating options is not just a question of SVR4 compatibility; it's 
also a question of following conventions to make it more familiar.

e.g., -h == help
      -v == verbose
      -V == Version info
      -c == alternate configfile
      -d == directory spec
      -i == install
      -l == long output
      -n == don't do it but tell me what you want to do
      -o == output
      -q == query status returned
      -R == recurse
      -t == set a type
      -u == uninstall

-- 
steveo at syslang dot net TMMP1 http://frambors.syslang.net/
Do you have neighbors who are not frambors? Steven W. Orr

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

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

     (( ${!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

Re: [Bashburn-info] Install.sh options

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

On Mon, 29 Sep 2008 11:21:52 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:

> On Monday, Sep 29th 2008 at 09:18 -0000, quoth Steven W. Orr:
> 
> =>On Monday, Sep 29th 2008 at 06:37 -0000, quoth Nick Warne:
> =>
> =>=>
> =>=>I have hardened the Install file options, after I noticed some
> strange =>=>behaviour with silly options (i.e. -uninstall ).
> =>=>
> =>=>There is still a big issue if you use:
> =>=>
> =>=>-prefix=/usr
> =>=>
> =>=>The install script will install into a directory called 'refix'
> in the =>=>current directory.
> =>=>
> =>=>Nick
> =>
> =>That should not happen. I'll look at it. :-( (after svn comes back
> up)
> 
> Nick, I haven't seen the change you made, but let me explain what's 
> happening.
> 
> The getopt/getopts calls are SVR4 compliant. That means that if you
> have a bunch of legal options, like a, b and c, then
> 
> foo -abc 
> is the same as
> 
> foo -a -b -c
> 
> In this case, we have long options. Every longopt has to have a 
> corresponding single letter option (to be SVR4 complient). In this
> case, we have -p and -u and -h. They have --prefix, --uninstall, and
> --help as long version.
> 
> The -p takes an argument, so if you say
> 
> Install.sh -prefix
> 
> then you get what the doctor ordered. You get -p with an option arg
> of refix. We probably should not be coding defensively around that.
> If the user was going to use the long option correctly then he would
> say
> 
> Install.sh --prefix dirname 
> or
> Install.sh --prefix=dirname 
> 
> But to just say -prefix is just wrong as the basis for something we
> should worry about.
> 
> Also note, if you say -p with no arg then that is caught as an error.
> 
> Does this help?
> 

Well, I find it a bit brain dead if a user mistypes '--prefix' as
'-prefix' and it installs into a directory called 'refix'.

BTW, SVN is back up

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] Install.sh options

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

On Monday, Sep 29th 2008 at 09:18 -0000, quoth Steven W. Orr:

=>On Monday, Sep 29th 2008 at 06:37 -0000, quoth Nick Warne:
=>
=>=>
=>=>I have hardened the Install file options, after I noticed some strange
=>=>behaviour with silly options (i.e. -uninstall ).
=>=>
=>=>There is still a big issue if you use:
=>=>
=>=>-prefix=/usr
=>=>
=>=>The install script will install into a directory called 'refix' in the
=>=>current directory.
=>=>
=>=>Nick
=>
=>That should not happen. I'll look at it. :-( (after svn comes back up)

Nick, I haven't seen the change you made, but let me explain what's 
happening.

The getopt/getopts calls are SVR4 compliant. That means that if you have a 
bunch of legal options, like a, b and c, then

foo -abc 
is the same as

foo -a -b -c

In this case, we have long options. Every longopt has to have a 
corresponding single letter option (to be SVR4 complient). In this case, 
we have -p and -u and -h. They have --prefix, --uninstall, and --help as 
long version.

The -p takes an argument, so if you say

Install.sh -prefix

then you get what the doctor ordered. You get -p with an option arg of 
refix. We probably should not be coding defensively around that. If the 
user was going to use the long option correctly then he would say

Install.sh --prefix dirname 
or
Install.sh --prefix=dirname 

But to just say -prefix is just wrong as the basis for something we should 
worry about.

Also note, if you say -p with no arg then that is caught as an error.

Does this help?

-- 
steveo at syslang dot net TMMP1 http://frambors.syslang.net/
Do you have neighbors who are not frambors? Steven W. Orr