bashburn-info Mailing List for BashBurn (Page 15)
Brought to you by:
bashburn
Menu
▾
▴
bashburn-info — BashBurn mailing list
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(3) |
Mar
|
Apr
(31) |
May
(5) |
Jun
(10) |
Jul
(21) |
Aug
(9) |
Sep
(9) |
Oct
(5) |
Nov
|
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(4) |
Feb
(7) |
Mar
|
Apr
(6) |
May
(1) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
(7) |
Nov
(3) |
Dec
(17) |
| 2007 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
(8) |
Aug
(114) |
Sep
(283) |
Oct
(128) |
Nov
|
Dec
(1) |
|
From: Nick W. <ni...@uk...> - 2008-09-05 20:20:52
|
On Fri, 5 Sep 2008 14:20:49 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > =>Trouble is here, Steve is how to test it. I don't have any stuff to > =>burn/discs to test with? > => > =>How can we test it all? > => > =>Is there a switch in cdrecord & friends that goes through the > motions =>(like --dry-run) and just pretends to burn something? > > I see a -dummy option on cdrecord: > > -dummy The CD/DVD-Recorder will go through all steps of the > recording process, but the laser is turned off during this > procedure. It is recommended to run several tests before actually > writing to a Compact Disk or Digital Versatile Disk, if the timing > and load response of the system is not known. > > Is this useful? I dunno. Before the changes did you try it - and after did you try it to see if it works? Do you actually use BB? That sounds rude, but isn't meant so. Surely only change things one step at a time - please don't break current functionality of BB to be _able_ to burn/rip etc. to not be able to do it. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Steven W. O. <st...@sy...> - 2008-09-05 18:20:44
|
On Friday, Sep 5th 2008 at 04:56 -0000, quoth Nick Warne:
=>On Thu, 4 Sep 2008 23:58:50 -0400 (EDT)
=>"Steven W. Orr" <st...@sy...> wrote:
=>
=>> I'm fixing so many things here that I must be breaking things.
=>>
=>> * data_burning seems to think that BBLABEL is allowed to have some
=>> special escape value called '<ask-me>'. If it does then it asks for a
=>> value and does not update the configuration file. Is this correct
=>> behavior in any world? What is correct?
=>>
=>> * I need people to closely look at what I did in burning.sh and
=>> audiofunc.sh There are lots of changes. The code that I touched was
=>> in many cases obviously broken and could never have worked in the
=>> past.
=>
=>Trouble is here, Steve is how to test it. I don't have any stuff to
=>burn/discs to test with?
=>
=>How can we test it all?
=>
=>Is there a switch in cdrecord & friends that goes through the motions
=>(like --dry-run) and just pretends to burn something?
I see a -dummy option on cdrecord:
-dummy The CD/DVD-Recorder will go through all steps of the recording
process, but the laser is turned off during this procedure. It
is recommended to run several tests before actually writing to a
Compact Disk or Digital Versatile Disk, if the timing and load
response of the system is not known.
Is this useful?
--
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-05 08:56:00
|
On Thu, 4 Sep 2008 23:58:50 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > I'm fixing so many things here that I must be breaking things. > > * data_burning seems to think that BBLABEL is allowed to have some > special escape value called '<ask-me>'. If it does then it asks for a > value and does not update the configuration file. Is this correct > behavior in any world? What is correct? > > * I need people to closely look at what I did in burning.sh and > audiofunc.sh There are lots of changes. The code that I touched was > in many cases obviously broken and could never have worked in the > past. Trouble is here, Steve is how to test it. I don't have any stuff to burn/discs to test with? How can we test it all? Is there a switch in cdrecord & friends that goes through the motions (like --dry-run) and just pretends to burn something? Nick -- Free Software Foundation Associate Member 5508 |
|
From: Fabian S. <fa...@sc...> - 2008-09-05 05:34:42
|
Steven W. Orr wrote: > I'm fixing so many things here that I must be breaking things. > > * data_burning seems to think that BBLABEL is allowed to have some special > escape value called '<ask-me>'. If it does then it asks for a value and > does not update the configuration file. Is this correct behavior in any > world? What is correct? > The idea behind this is, that some persons, including me, don't want every CD to have the same label. So it is easier to be asked every time just when burning the CD, than always going to the options menu, which you might forget easily. |
|
From: Steven W. O. <st...@sy...> - 2008-09-05 03:58:42
|
I'm fixing so many things here that I must be breaking things.
* data_burning seems to think that BBLABEL is allowed to have some special
escape value called '<ask-me>'. If it does then it asks for a value and
does not update the configuration file. Is this correct behavior in any
world? What is correct?
* I need people to closely look at what I did in burning.sh and
audiofunc.sh There are lots of changes. The code that I touched was in
many cases obviously broken and could never have worked in the past.
* There are a lot of global variables that were removed. Look at
set_session_type and dvd_data_burning for an example.
* I identified a lot of variables that needed to be made local and flipped
them all to lower case.
* In the function encode_filter, it looks at the value of $ENCODEFILTER
and does something. AFAICT, ENCODEFILTER is never set. encode_filter is
called in a bunch of places in audiofunc.sh
* I consolidated a lot of functions is audiofunc.sh
* There were about a zillion calls to wait_for_enter. Most have been
removed because they were set up a la
if xxx
then
do somthing
wait_for_enter
else
do somthing else
wait_for_enter
fi
Now they look like
if xxx
then
do somthing
else
do somthing else
fi
wait_for_enter
* I need someone to look at dvd_image_burn. It's flat out wrong.
if ${BB_DVDBURNCMD} -dvd-compat \
-Z ${BBCDWRITER}=${BBBURNDIR}/$(ls ${BBBURNDIR} | grep -i $imagetype)
This is just plain illegal syntax. I don't understand what the goal is.
Tell me and I can fix it.
* pipeline_burning had a number of variables that were mis-spelled. I need
people to look at this and verify. Look at a variable that used to be
there called IFOF. :-(
* There was a wackobanana construct in pipeline_burning that made me very
sad:
echo ${COUNTER-MP3} $( echo $(basename "${FILE}") | head -c35 ) \
flushed into ${FIFO} \(pipe\).
is now
pfile=${file##*/}
echo "${counter-MP3} ${pfile:0:35} flushed into ${fifo} (pipe)."
But I'd like to know where the 35 came from.
* All of the case management stuff is now exorcised via use of
shopt -s nocaseglob
shopt -u nocaseglob
So, to reiterate: PLEASE LOOK AT WHAT I DID. I need to be kept honest.
Like I said before, there were a number of things that clearly could never
have worked before.
--
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
|
|
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 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: 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 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 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 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: 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-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-03 17:06:52
|
Just a few ideas to pass along:
* In your .bash_profile
export PS4='+${0##*/} line $LINENO: '
* We clear the screen a lot so it's easy to not see error messages from
syntax problems, etc...
* Run the script program and then run bashburn. Then exit from script and
you can look at the typescript file afterwards. You might have to run
dos2unix on the file.
* Bracket the code you need to debug with
set -x
stuff
set+x
so you can see what's happening.
BTW, I've gotten a few tips on how to make life easier with svn. If people
have more tips I'd love to hear them.
--
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 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: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 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: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: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: 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: 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: 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: 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: 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
|
8 messages has been excluded from this view by a project administrator.
