Thread: [Bashburn-info] Substantial change to the configure function.
Brought to you by:
bashburn
Menu
▾
▴
bashburn-info
|
From: Steven W. O. <st...@sy...> - 2008-09-03 05:00:08
|
We now have a Revert function in the Configure option.
If you change a value, it will not take place until you Apply it. If you
Revert, then all changes will be wiped out.
This is a rather substantial change and I (as usual) think I got it right.
No bets.
There is some English language text in configure.
And finally, the BashBurn.sh had to get re-structured. It's vital that all
sourcing not happen from the context of a subroutine. To make a long story
short:
-------bar.sh------
typeset -ri intval=44
------end of bar.sh
foo()
{
. bar.sh
}
will cause intval to be a local variable inside foo and never globally
available. You might not care except that I still want the option of
creating and declaring global variables.
Enjoy. It's 1AM and I'm outtahee.
--
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...@uk...> - 2008-09-03 06:26:03
|
On Wed, 3 Sep 2008 01:00:17 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:
> We now have a Revert function in the Configure option.
>
> If you change a value, it will not take place until you Apply it. If
> you Revert, then all changes will be wiped out.
>
> This is a rather substantial change and I (as usual) think I got it
> right. No bets.
>
> There is some English language text in configure.
>
> And finally, the BashBurn.sh had to get re-structured. It's vital
> that all sourcing not happen from the context of a subroutine. To
> make a long story short:
>
> -------bar.sh------
>
> typeset -ri intval=44
>
> ------end of bar.sh
>
> foo()
> {
> . bar.sh
> }
>
> will cause intval to be a local variable inside foo and never
> globally available. You might not care except that I still want the
> option of creating and declaring global variables.
>
> Enjoy. It's 1AM and I'm outtahee.
>
OK, I get syntax errors when starting... it looks like bash doesn't
like empty functions. If I remove them, all seems well but I don't
know what you was doing here so haven't changed anything.
line 285: syntax error near unexpected token `}'
source_language_modules()
{
} <---------------------------------
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Nick W. <ni...@uk...> - 2008-09-03 06:52:29
|
On Wed, 3 Sep 2008 07:26:10 +0100
Nick Warne <ni...@uk...> wrote:
> On Wed, 3 Sep 2008 01:00:17 -0400 (EDT)
> "Steven W. Orr" <st...@sy...> wrote:
>
> > We now have a Revert function in the Configure option.
> >
> > If you change a value, it will not take place until you Apply it. If
> > you Revert, then all changes will be wiped out.
> >
> > This is a rather substantial change and I (as usual) think I got it
> > right. No bets.
> >
> > There is some English language text in configure.
> >
> > And finally, the BashBurn.sh had to get re-structured. It's vital
> > that all sourcing not happen from the context of a subroutine. To
> > make a long story short:
> >
> > -------bar.sh------
> >
> > typeset -ri intval=44
> >
> > ------end of bar.sh
> >
> > foo()
> > {
> > . bar.sh
> > }
> >
> > will cause intval to be a local variable inside foo and never
> > globally available. You might not care except that I still want the
> > option of creating and declaring global variables.
> >
> > Enjoy. It's 1AM and I'm outtahee.
> >
>
> OK, I get syntax errors when starting... it looks like bash doesn't
> like empty functions. If I remove them, all seems well but I don't
> know what you was doing here so haven't changed anything.
>
> line 285: syntax error near unexpected token `}'
>
> source_language_modules()
> {
> } <---------------------------------
>
I get around the above error by adding a 'continue'.
Another thing is 'apply changes' doesn't work.
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Steven W. O. <st...@sy...> - 2008-09-03 14:04:28
|
On Wednesday, Sep 3rd 2008 at 02:26 -0000, quoth Nick Warne:
=>On Wed, 3 Sep 2008 01:00:17 -0400 (EDT)
=>"Steven W. Orr" <st...@sy...> wrote:
=>
=>> We now have a Revert function in the Configure option.
=>>
=>> If you change a value, it will not take place until you Apply it. If
=>> you Revert, then all changes will be wiped out.
=>>
=>> This is a rather substantial change and I (as usual) think I got it
=>> right. No bets.
=>>
=>> There is some English language text in configure.
=>>
=>> And finally, the BashBurn.sh had to get re-structured. It's vital
=>> that all sourcing not happen from the context of a subroutine. To
=>> make a long story short:
=>>
=>> -------bar.sh------
=>>
=>> typeset -ri intval=44
=>>
=>> ------end of bar.sh
=>>
=>> foo()
=>> {
=>> . bar.sh
=>> }
=>>
=>> will cause intval to be a local variable inside foo and never
=>> globally available. You might not care except that I still want the
=>> option of creating and declaring global variables.
=>>
=>> Enjoy. It's 1AM and I'm outtahee.
=>>
=>
=>OK, I get syntax errors when starting... it looks like bash doesn't
=>like empty functions. If I remove them, all seems well but I don't
=>know what you was doing here so haven't changed anything.
=>
=>line 285: syntax error near unexpected token `}'
=>
=>source_language_modules()
=>{
=>} <---------------------------------
This goes to show that committing at 01:30 is risky business.
BTW, bash is correct. A function is not allowed to be empty. There must be
something there. The standard null statement is:
:
continue or break have no meaning outside of the context of a loop.
But you did identify another minor problem in configure.sh. Please
update.
Thanks.
--
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: Steven W. O. <st...@sy...> - 2008-09-03 14:13:10
|
I wanted to followup to my previous message about sourcing files from within functions. This is sort of a key issue and I'm writing this down as much to hammer it into my own skull as much as to impart my pearls to the rest of the world. If you have a variable that is to be considered a global, i.e., everyone else (or anyone else) may want to reference it, and that variable is being sourced in from a subroutine call, then that variable declaration may not be declared with a typeset statement. If you do then the variable will not be global. Instead, it will end up as local to the function that sourced the file in. -- 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...@uk...> - 2008-09-03 14:13:33
|
On Wed, 3 Sep 2008 10:04:34 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:
> =>
> =>OK, I get syntax errors when starting... it looks like bash doesn't
> =>like empty functions. If I remove them, all seems well but I don't
> =>know what you was doing here so haven't changed anything.
> =>
> =>line 285: syntax error near unexpected token `}'
> =>
> =>source_language_modules()
> =>{
> =>} <---------------------------------
>
> This goes to show that committing at 01:30 is risky business.
>
>
> BTW, bash is correct. A function is not allowed to be empty. There
> must be something there. The standard null statement is:
>
> :
>
> continue or break have no meaning outside of the context of a loop.
>
> But you did identify another minor problem in configure.sh. Please
> update.
Steve,
Still doesn't save any changes to configuration. It shows the changed
value* perfectly (good idea!), but applying changes doesn't save.
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Nick W. <ni...@uk...> - 2008-09-03 16:01:45
|
On Wed, 3 Sep 2008 15:13:42 +0100
Nick Warne <ni...@uk...> wrote:
> On Wed, 3 Sep 2008 10:04:34 -0400 (EDT)
> "Steven W. Orr" <st...@sy...> wrote:
>
> > =>
> > =>OK, I get syntax errors when starting... it looks like bash
> > doesn't =>like empty functions. If I remove them, all seems well
> > but I don't =>know what you was doing here so haven't changed
> > anything. =>
> > =>line 285: syntax error near unexpected token `}'
> > =>
> > =>source_language_modules()
> > =>{
> > =>} <---------------------------------
> >
> > This goes to show that committing at 01:30 is risky business.
> >
> >
> > BTW, bash is correct. A function is not allowed to be empty. There
> > must be something there. The standard null statement is:
> >
> > :
> >
> > continue or break have no meaning outside of the context of a loop.
> >
> > But you did identify another minor problem in configure.sh. Please
> > update.
>
> Steve,
>
> Still doesn't save any changes to configuration. It shows the changed
> value* perfectly (good idea!), but applying changes doesn't save.
>
> Nick
Can anybody else please svn update and check to see if you can save
changes please. This is doing me and Steve in, It works for him, but
not for me.
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Steven W. O. <st...@sy...> - 2008-09-03 14:30:29
|
On Wednesday, Sep 3rd 2008 at 10:13 -0000, quoth Nick Warne: =>Still doesn't save any changes to configuration. It shows the changed =>value* perfectly (good idea!), but applying changes doesn't save. I deleted all src files, deleted $BBROOT and re-updated. I also found a small change that got lost that has nothing to do with this. We're currently at 496 and it seems to work fine. Can you make sure you're in sync? -- 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...@uk...> - 2008-09-03 14:39:23
|
On Wed, 3 Sep 2008 10:30:34 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:
> On Wednesday, Sep 3rd 2008 at 10:13 -0000, quoth Nick Warne:
>
>
> =>Still doesn't save any changes to configuration. It shows the
> changed =>value* perfectly (good idea!), but applying changes doesn't
> save.
>
> I deleted all src files, deleted $BBROOT and re-updated. I also found
> a small change that got lost that has nothing to do with this.
>
> We're currently at 496 and it seems to work fine. Can you make sure
> you're in sync?
>
Yep, current version.
I just deleted .bashburnrc and uninstalled/re-installed. Same issue.
I can change something, and see it marked*. The 'apply changes'
doesn't change it - as the value reverts back to the old value.
As an aside, in Bashburn.sh there is duplicate sourcing of
. ${BBROOTDIR}/misc/commonfunctions.sh
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Steven W. O. <st...@sy...> - 2008-09-03 14:49:11
|
On Wednesday, Sep 3rd 2008 at 10:39 -0000, quoth Nick Warne:
=>On Wed, 3 Sep 2008 10:30:34 -0400 (EDT)
=>"Steven W. Orr" <st...@sy...> wrote:
=>
=>> On Wednesday, Sep 3rd 2008 at 10:13 -0000, quoth Nick Warne:
=>>
=>>
=>> =>Still doesn't save any changes to configuration. It shows the
=>> changed =>value* perfectly (good idea!), but applying changes doesn't
=>> save.
=>>
=>> I deleted all src files, deleted $BBROOT and re-updated. I also found
=>> a small change that got lost that has nothing to do with this.
=>>
=>> We're currently at 496 and it seems to work fine. Can you make sure
=>> you're in sync?
=>>
=>
=>Yep, current version.
=>
=>I just deleted .bashburnrc and uninstalled/re-installed. Same issue.
=>
=>I can change something, and see it marked*. The 'apply changes'
=>doesn't change it - as the value reverts back to the old value.
=>
=>As an aside, in Bashburn.sh there is duplicate sourcing of
=>
=>. ${BBROOTDIR}/misc/commonfunctions.sh
I fixed the dup. I have no idea what else to say. Can you diff this
attachment with what you have?
--
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...@uk...> - 2008-09-03 21:03:59
|
On Wed, 03 Sep 2008 18:42:43 +0200 Anders Lindén <and...@gm...> wrote: > > > Still doesn't save any changes to configuration. It shows the > > > changed value* perfectly (good idea!), but applying changes > > > doesn't save. > > > > > > Nick > > > > Can anybody else please svn update and check to see if you can save > > changes please. This is doing me and Steve in, It works for him, > > but not for me. > > > > Nick > > > > Seems to work fine here. I change, apply an option and .bashburnrc is > updated. One thing I noticed though is that if I change an option and > want to change it again (In the same session), the menu wont update to > show my second change, only the first. OK, I am at my wits end. I have tried everything. I totally removed everything *bashburn* from my system. I re-installed. Same issue - config changes do not get saved. I totally removed everything *bashburn* from my system, trashed my local SVN and re-checked out. Same issue - config changes do not get saved. I totally removed everything *bashburn* from my system. I unhashed bash (hash -r). I re-installed using default install (I use the Slackware option). Same issue - config changes do not get saved. I dunno what else to try, really I don't. I guess next step is for me to revert to an early version and find what/when broke for me... Nick -- Free Software Foundation Associate Member 5508 |
|
From: Steven W. O. <st...@sy...> - 2008-09-04 04:08:20
|
On Wednesday, Sep 3rd 2008 at 17:04 -0000, quoth Nick Warne:
=>OK, I am at my wits end. I have tried everything. I totally removed
=>everything *bashburn* from my system.
This is good. I've only lost half of my wits. ;-)
=>I re-installed.
=>
=>Same issue - config changes do not get saved.
=>
=>I totally removed everything *bashburn* from my system, trashed my
=>local SVN and re-checked out.
=>
=>Same issue - config changes do not get saved.
=>
=>I totally removed everything *bashburn* from my system. I unhashed
=>bash (hash -r). I re-installed using default install (I use the
=>Slackware option).
=>
=>Same issue - config changes do not get saved.
=>
=>I dunno what else to try, really I don't.
=>
=>I guess next step is for me to revert to an early version and find
=>what/when broke for me...
You're right. It does sound desperate. Let's do this.
Mod your local copy of apply_options.sh and in the function conf_set_aval,
put a set -x set +x around the while read loop. It should look like this:
set -x
while read line
do
IFS=:
<stuff>
done < $BBCONFFILE > $tmpfile
set +x
Start script and from there run bb.
Go into configure and change one thing.
Then apply.
Exit bb.
Exit script.
By looking at the trace, you should see:
the value of size should be 1.
The value of desc[0] should be "theVarYouChanged:newval"
Send me the typescript file.
--
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...@uk...> - 2008-09-04 06:21:34
|
On Thu, 4 Sep 2008 00:08:25 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > Go into configure and change one thing. > > Then apply. > > Exit bb. > > Exit script. > > By looking at the trace, you should see: > the value of size should be 1. > The value of desc[0] should be "theVarYouChanged:newval" > > Send me the typescript file. Good man - I am NOT bonkers :-) Please enter 'n' (Back) ^[[1;31m|^[[1;0m 'y' (Apply changes) ^[[1;31m+--------------+-------------+--------------+^[[1;0m ^[[1;35m|> ^[[1;0my mktemp: cannot create temp file bbcfg.XXXXX: Invalid argument /usr/bin/BashBurn/config/apply_options.sh: line 48: $tmpfile: ambiguous redirect cp: missing destination file operand after `/home/nick/.bashburnrc' Try `cp --help' for more information. rm: missing operand Try `rm --help' for more information. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@uk...> - 2008-09-04 06:43:22
|
On Thu, 4 Sep 2008 07:21:39 +0100 Nick Warne <ni...@uk...> wrote: > > By looking at the trace, you should see: > > the value of size should be 1. > > The value of desc[0] should be "theVarYouChanged:newval" > > > > Send me the typescript file. > > Good man - I am NOT bonkers :-) > > Please enter 'n' (Back) ^[[1;31m|^[[1;0m 'y' (Apply changes) > ^[[1;31m+--------------+-------------+--------------+^[[1;0m > ^[[1;35m|> ^[[1;0my > mktemp: cannot create temp file bbcfg.XXXXX: Invalid argument > /usr/bin/BashBurn/config/apply_options.sh: line 48: $tmpfile: > ambiguous redirect cp: missing destination file operand after > `/home/nick/.bashburnrc' Try `cp --help' for more information. > rm: missing operand > Try `rm --help' for more information. OK, I got it to work :-))) It doesn't like the double declaration of 'tmpfile' in the two functions. If I change the second decl. in conf_set_aval() to 'tmpfile2' all works well. For info: 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: Nick W. <ni...@uk...> - 2008-09-04 08:48:30
|
On Thu, 4 Sep 2008 07:43:28 +0100 Nick Warne <ni...@uk...> wrote: > It doesn't like the double declaration of 'tmpfile' in the two > functions. > > If I change the second decl. in conf_set_aval() to 'tmpfile2' all > works well. OK, I am talking twaddle. I found the real fix (I must have changed it correctly while debugging/changing lines). I have committed - please update. Steve: You will KICK YOURSELF. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@uk...> - 2008-09-04 09:03:56
|
On Thu, 4 Sep 2008 09:48:36 +0100 Nick Warne <ni...@uk...> wrote: > On Thu, 4 Sep 2008 07:43:28 +0100 > Nick Warne <ni...@uk...> wrote: > > > It doesn't like the double declaration of 'tmpfile' in the two > > functions. > > > > If I change the second decl. in conf_set_aval() to 'tmpfile2' all > > works well. > > OK, I am talking twaddle. I found the real fix (I must have changed > it correctly while debugging/changing lines). > > I have committed - please update. > > Steve: You will KICK YOURSELF. > > Nick Thinking, it's a wonder why it worked for anybody??? Nick -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@uk...> - 2008-09-04 09:09:43
|
On Wed, 03 Sep 2008 18:42:43 +0200 Anders Lindén <and...@gm...> wrote: > > Can anybody else please svn update and check to see if you can save > > changes please. This is doing me and Steve in, It works for him, > > but not for me. > > > > Nick > > > > Seems to work fine here. I change, apply an option and .bashburnrc is > updated. One thing I noticed though is that if I change an option and > want to change it again (In the same session), the menu wont update to > show my second change, only the first. OK, now I got 'apply changes' to function, I also see above behaviour. Also if you change several options, only the first one gets shown*. But then apply, and your options do indeed get changed. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Steven W. O. <st...@sy...> - 2008-09-04 17:06:10
|
On Thursday, Sep 4th 2008 at 05:04 -0000, quoth Nick Warne: =>On Thu, 4 Sep 2008 09:48:36 +0100 =>Nick Warne <ni...@uk...> wrote: => =>> On Thu, 4 Sep 2008 07:43:28 +0100 =>> Nick Warne <ni...@uk...> wrote: =>> =>> > It doesn't like the double declaration of 'tmpfile' in the two =>> > functions. =>> > =>> > If I change the second decl. in conf_set_aval() to 'tmpfile2' all =>> > works well. =>> =>> OK, I am talking twaddle. I found the real fix (I must have changed =>> it correctly while debugging/changing lines). =>> =>> I have committed - please update. =>> =>> Steve: You will KICK YOURSELF. =>> =>> Nick => =>Thinking, it's a wonder why it worked for anybody??? => =>Nick Ok. I got it. Resync please. I'm up to 502. Here's an interesting thing: I changed BBOPT_ONE to Hello and then found I could not change it back to a null string. Empty input apparantly was an escape for "please don't do anything". I changed it so that empty input now means "Set it to the null string." But, you have revert to get back if you don't like it. Nick, the change you made was to increase the number of Xs in the template from 5 to 6? Is that it? If so then I need to change all of the templates? -- 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...@uk...> - 2008-09-04 19:01:50
|
On Thu, 4 Sep 2008 13:06:14 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:
> On Thursday, Sep 4th 2008 at 05:04 -0000, quoth Nick Warne:
>
> =>On Thu, 4 Sep 2008 09:48:36 +0100
> =>Nick Warne <ni...@uk...> wrote:
> =>
> =>> On Thu, 4 Sep 2008 07:43:28 +0100
> =>> Nick Warne <ni...@uk...> wrote:
> =>>
> =>> > It doesn't like the double declaration of 'tmpfile' in the two
> =>> > functions.
> =>> >
> =>> > If I change the second decl. in conf_set_aval() to 'tmpfile2'
> all =>> > works well.
> =>>
> =>> OK, I am talking twaddle. I found the real fix (I must have
> changed =>> it correctly while debugging/changing lines).
> =>>
> =>> I have committed - please update.
> =>>
> =>> Steve: You will KICK YOURSELF.
> =>>
> =>> Nick
> =>
> =>Thinking, it's a wonder why it worked for anybody???
> =>
> =>Nick
>
> Ok. I got it. Resync please. I'm up to 502.
>
> Here's an interesting thing: I changed BBOPT_ONE to Hello and then
> found I could not change it back to a null string. Empty input
> apparantly was an escape for "please don't do anything". I changed it
> so that empty input now means "Set it to the null string." But, you
> have revert to get back if you don't like it.
>
> Nick, the change you made was to increase the number of Xs in the
> template from 5 to 6? Is that it? If so then I need to change all of
> the templates?
>
DESCRIPTION
The mktemp utility takes the given filename template and
overwrites a portion of it to create a unique filename. The template
may be any filename with six (6) `Xs' appended to it, for
example /tmp/tfile.XXXXXX. If no template is specified a default of
tmp.XXXXXX is used and the -t flag is implied (see below).
I think all the others have 6 anyway.
Nick
--
Free Software Foundation Associate Member 5508
|
Thanks for helping keep SourceForge clean.
X