bashburn-info — BashBurn mailing list

[Bashburn-info] Another error in config

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

Lots of error reports tonight :)

When I reset the options in the regular configure menu and then exit BB,
the next time I enter the advanced config, all options are zeroed out. A
reset in config should not affect the advanced options at all.
-- 
Anders Lindén
http://bashburn.sf.net

Re: [Bashburn-info] Error in advanced menu

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

It also seems that in the regular configure menu, help text is only
displayed in English, not the selected language. The menu itself is
translated correctly though.

On Mon, 2008-09-22 at 01:14 +0200, Anders Lindén wrote:
> The advanced menu does not display any information anymore when
> selecting an option. Did I break something or did you Steven?
> 
> 
-- 
Anders Lindén
http://bashburn.sf.net

[Bashburn-info] Error in advanced menu

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

The advanced menu does not display any information anymore when
selecting an option. Did I break something or did you Steven?


-- 
Anders Lindén
http://bashburn.sf.net

Re: [Bashburn-info] SVN issue

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

SVN is back up. Dunno why it was down.

On Sun, 2008-09-21 at 11:43 +0100, Nick Warne wrote:
> Anybody else have issue with the SVN server today (it's AWOL) - or is
> it just me?
> 
> Nick
-- 
Anders Lindén
http://bashburn.sf.net

Re: [Bashburn-info] I think I fixed the AUTHOR problem.

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

Yeah thats pretty much what I meant. Telling the shell which characters
are to be used to separate fields.

Question, why are you setting a new IFS and shortly after set it back to
the old IFS in loops?
Is it because programs used in the loop needs the original IFS to work
properly?

On another note, I noticed when starting the latest svn snapshot of BB,
it spits out an error message
that the command die does not exist. I'm guessing because you have not
sourced the needed file yet at that point.   


On Sun, 2008-09-21 at 18:20 -0400, Steven W. Orr wrote:
> On Sunday, Sep 21st 2008 at 16:34 -0000, quoth Anders Lind?n:
> 
> =>Meh, I sent my reply to Steven and not the list. Reposting it here.
> =>
> =>If I'm not mistaken, IFS is something that is treated as a space or
> =>newline character no? You can set a character like @, : or | in our case
> =>to be treated as a whitespace to separate text fields?
> =>
> =>On Sun, 2008-09-21 at 16:17 -0400, Steven W. Orr wrote:
> =>> It looks like we have three different values that are being used for IFS. 
> =>> There's the IFS=: which is needed to read a bbrc file. There's IFS=@ used 
> =>> to pass uneval'd data to bbconfmenu. And now there's IFS='|' which is 
> =>> needed to store configure_changes. (BTW, the implication is that a config 
> =>> val may no longer contain an embedded pipe char.)
> =>> 
> =>> Nick, I hope this works. There's always one guy who screws up and makes 
> =>> people aware that he's good at testing. I consider it a blessing. ;-) The 
> =>> good news is that if you find anything wrong with it, it should be easy to 
> =>> fix. (I try to never let people know that I know how to get the printer
> =>> working. ;-)
> =>> 
> =>> On a related topic, I was just curious. Do people understand what IFS is 
> =>> and what I'm doing with it? How it gets restored? etc...?
> 
> Close. IFS is used as the mechanism to tell bash how to parse text. For 
> example, if I have
> 
> foo='This is a string: It has some stuff in it. And it's 2:00PM.'
> then I can say
> set -- $foo
> After the set command, 
> $1 will be 'This'
> $2 will be 'is'
> $3 will be 'a'
> and $4 will be 'string:'
> 
> But if I was to say
> IFS=:
> set -- $foo
> then $1 will be 'This is a string'
> $2 will be ' It has some stuff in it. And it's 2'
> and $3 will be '00PM.'
> 
> In addition, lists will be taken apart differently (for example is for 
> loops, depending on IFS. All the values of IFS that I work with are local 
> copies in subroutines. e.g.,
> 
> subX()
> {
>     typeset old_IFS="$IFS"
>     typeset IFS="$old_IFS"
> 
> The default value for IFS is whitespace
> 
> 533 > echo "$IFS" | od -bc
> 0000000 040 011 012 012
>              \t  \n  \n
> 0000004
> 
> 
-- 
Anders Lindén
http://bashburn.sf.net

Re: [Bashburn-info] I think I fixed the AUTHOR problem.

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

On Sunday, Sep 21st 2008 at 16:34 -0000, quoth Anders Lind?n:

=>Meh, I sent my reply to Steven and not the list. Reposting it here.
=>
=>If I'm not mistaken, IFS is something that is treated as a space or
=>newline character no? You can set a character like @, : or | in our case
=>to be treated as a whitespace to separate text fields?
=>
=>On Sun, 2008-09-21 at 16:17 -0400, Steven W. Orr wrote:
=>> It looks like we have three different values that are being used for IFS. 
=>> There's the IFS=: which is needed to read a bbrc file. There's IFS=@ used 
=>> to pass uneval'd data to bbconfmenu. And now there's IFS='|' which is 
=>> needed to store configure_changes. (BTW, the implication is that a config 
=>> val may no longer contain an embedded pipe char.)
=>> 
=>> Nick, I hope this works. There's always one guy who screws up and makes 
=>> people aware that he's good at testing. I consider it a blessing. ;-) The 
=>> good news is that if you find anything wrong with it, it should be easy to 
=>> fix. (I try to never let people know that I know how to get the printer
=>> working. ;-)
=>> 
=>> On a related topic, I was just curious. Do people understand what IFS is 
=>> and what I'm doing with it? How it gets restored? etc...?

Close. IFS is used as the mechanism to tell bash how to parse text. For 
example, if I have

foo='This is a string: It has some stuff in it. And it's 2:00PM.'
then I can say
set -- $foo
After the set command, 
$1 will be 'This'
$2 will be 'is'
$3 will be 'a'
and $4 will be 'string:'

But if I was to say
IFS=:
set -- $foo
then $1 will be 'This is a string'
$2 will be ' It has some stuff in it. And it's 2'
and $3 will be '00PM.'

In addition, lists will be taken apart differently (for example is for 
loops, depending on IFS. All the values of IFS that I work with are local 
copies in subroutines. e.g.,

subX()
{
    typeset old_IFS="$IFS"
    typeset IFS="$old_IFS"

The default value for IFS is whitespace

533 > echo "$IFS" | od -bc
0000000 040 011 012 012
             \t  \n  \n
0000004


-- 
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] I think I fixed the AUTHOR problem.

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

Meh, I sent my reply to Steven and not the list. Reposting it here.

If I'm not mistaken, IFS is something that is treated as a space or
newline character no? You can set a character like @, : or | in our case
to be treated as a whitespace to separate text fields?

On Sun, 2008-09-21 at 16:17 -0400, Steven W. Orr wrote:
> It looks like we have three different values that are being used for IFS. 
> There's the IFS=: which is needed to read a bbrc file. There's IFS=@ used 
> to pass uneval'd data to bbconfmenu. And now there's IFS='|' which is 
> needed to store configure_changes. (BTW, the implication is that a config 
> val may no longer contain an embedded pipe char.)
> 
> Nick, I hope this works. There's always one guy who screws up and makes 
> people aware that he's good at testing. I consider it a blessing. ;-) The 
> good news is that if you find anything wrong with it, it should be easy to 
> fix. (I try to never let people know that I know how to get the printer
> working. ;-)
> 
> On a related topic, I was just curious. Do people understand what IFS is 
> and what I'm doing with it? How it gets restored? etc...?
> 
-- 
Anders Lindén
http://bashburn.sf.net

[Bashburn-info] I think I fixed the AUTHOR problem.

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

It looks like we have three different values that are being used for IFS. 
There's the IFS=: which is needed to read a bbrc file. There's IFS=@ used 
to pass uneval'd data to bbconfmenu. And now there's IFS='|' which is 
needed to store configure_changes. (BTW, the implication is that a config 
val may no longer contain an embedded pipe char.)

Nick, I hope this works. There's always one guy who screws up and makes 
people aware that he's good at testing. I consider it a blessing. ;-) The 
good news is that if you find anything wrong with it, it should be easy to 
fix. (I try to never let people know that I know how to get the printer
working. ;-)

On a related topic, I was just curious. Do people understand what IFS is 
and what I'm doing with it? How it gets restored? etc...?

-- 
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] have a bash compatibility question

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

On Sat, 20 Sep 2008 20:42:23 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:

> =>By the way - what does everyone think - should we use unicode
> (UTF8) for =>encoding the translations in bashburn 3?
> =>This also means we have to switch console to unicode
> ("unicode_start")?
> 
> I have never looked at unicode. I suppose it's part of the fact that 
> Americans only speak one language ;-)

I have messed about with UTF8 before, and it messes my shell up (e.g.
there is a bug in grep using the --color option).

But again, using English, I have never had any real reason to use UTF8.

Perhaps the languages that require it can use it - but you have to
remember (I think) the shell/system needs to be set to UTF8 anyway.

Nick
-- 
Free Software Foundation Associate Member 5508

[Bashburn-info] SVN issue

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

Anybody else have issue with the SVN server today (it's AWOL) - or is
it just me?

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] have a bash compatibility question

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

On Saturday, Sep 20th 2008 at 17:15 -0000, quoth Markus Kollmar:

=>Steven W. Orr wrote:
=>> ---------- Forwarded message ----------
=>> Date: Fri, 19 Sep 2008 16:48:25
=>> From: Steven W. Orr <st...@sy...>
=>> To: bashburn <Bas...@li...>
=>> Subject: I have a bash compatibility question
=>> 
=>> What version of bash do we support? I run 3.0 here at home (currently) and
=>> at work I happen to have 3.2. Do we have to support version 2 or are my
=>> presumptions about 3 ok to be making?
=>> 
=>>   
=>Hm, Steven have you a special reason why we should support bash >= 3.0 ?
=>I first thought we should support bash versions which are older than 3.0 if we
=>have no special reason. But then I searched and found this:

The features that I have in mind (right now) are


=>
=>Bash-3.0 contained the following new features:
=>
=>o Features to support the bash debugger have been implemented, and there
=> is a new `extdebug' option to turn the non-default options on

I have not played with this yet.

=>o HISTCONTROL is now a colon-separated list of options and has been
=> extended with a new `erasedups' option that will result in only one
=> copy of a command being kept in the history list

Probably not relevant.

=>o Brace expansion has been extended with a new {x..y} form, producing
=> sequences of digits or characters

Very useful.
for ii in $(seq 0 9)
do
   ...

vs

for (( ii=0; ii < 10; ii++ ))
do
   ...

for ii in {0..9}
do
   ...

Looks useful.

=>o Timestamps are now kept with history entries, with an option to save
=> and restore them from the history file; there is a new HISTTIMEFORMAT
=> variable describing how to display the timestamps when listing history
=> entries

Not useful for bb.

=>
=>o The `[[' command can now perform extended regular expression (egrep-like)
=> matching, with matched subexpressions placed in the BASH_REMATCH array
=> variable

*Very* useful. The =~ is worth having to keep people fromn wishing they 
were working in perl or python. ;-)>

=>o A new `pipefail' option causes a pipeline to return a failure status if
=> any command in it fails

Haven't used it yet, but it's something I've had to fake in the past. 
Instead of...

p > tmp1
status=$?
q < tmp1 > tmp2
(( status|=$? ))
etc...

=>o The `jobs', `kill', and `wait' builtins now accept job control notation
=> in their arguments even if job control is not enabled

Not so much.

=>o The `gettext' package and libintl have been integrated, and the shell
=> messages may be translated into other languages

I guess that's what's on the plate next.

=>So, since we want to use gettext (in bashburn version 3) we have to use bash
=>version >= 3.0. Or am I wrong?
=>
=>By the way - what does everyone think - should we use unicode (UTF8) for
=>encoding the translations in bashburn 3?
=>This also means we have to switch console to unicode ("unicode_start")?

I have never looked at unicode. I suppose it's part of the fact that 
Americans only speak one language ;-)


-- 
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] A few issues

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

On Saturday, Sep 20th 2008 at 05:17 -0000, quoth Nick Warne:

=>
=>If you go to 5) Configuration, and select the 'author' option (No. 8),
=>you cannot enter an email@address - the value gets 'chomped' at the '@'.
=>
=>I had a brief look at the above, but can't see where it goes wrong.
=>

Hmm. Ok. I know what to do. Here's the situation:

The value of conf_menuitems[8] is

"$bb_conf_menu_auth@BBAUTHOR@${bb_conf_ch_author}"

Note the double quotes. And the value of bb_conf_ch_author is 

"This option describes the preparer of the disc, usually
with an e-mail and phone number. There is space for
128 characters of information.
The current setting is: ${BBOPTIONCOLOR}${BBAUTHOR}${BBCOLOROFF}.
${bb_conf_cancel_quote}"

Also, note the double quotes.

So what I'm going to do to fix this is...

and please don't expect it tonight...

and I really do hope I get it right so Nick doesn't find four things 
wrong with it...

is

(drumroll please)

I change the value of conf_menuitems[8] to

'bb_conf_menu_auth@BBAUTHOR@bb_conf_ch_author' # Using single quotes.

Then in bbmenuconf, I'll have to eval the three elements of the arg. That 
way, if the value of bb_conf_ch_author happens to contain an atsign, it 
won't screw anything up.



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

[Bashburn-info] Changelog

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

Forgot to mention, remember to update the changelog when you have done
something. We want people to see how awesome we are right? :)
-- 
Anders Lindén
http://bashburn.sf.net

[Bashburn-info] Quick rewrite of XMMS playlist burning script.

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

Like the topic says, I just did a quick rewrite (And renaming) of the
XMMS playlist burning script. The script reads through a M3U file,
skipping any line beginning with '#EXT' and links the filenames it finds
to the burn directory. The function calling the m3u_read function (Which
is what xmmsread is renamed to) then converts any audio files it finds
and burns them.
This rewritten script now supports ogg and flac files as well, not just
mp3. 
-- 
Anders Lindén
http://bashburn.sf.net

Re: [Bashburn-info] trunk: Remove xmmsread.sh?

[Fabian S. <fa...@sc...>]

>> I've been thinking about this, since XMMS is not developed anymore, is
>> there really a reason to keep the XMMS playlist burning functionality?
>>
>> Do people really use it? I suppose we could change it into "Burn
>> M3U-file" if people really want something like that. Thoughts?
>>     
>
> I think Audacious has superseded xmms (was/is a fork?)... whether they
> use the same file extensions, I do not know.  It could be just a case of
> tweaking a few names here and there to keep the similar functionality.
>   

I think burning M3U playlists makes sense and is a good feature. This
gives you the possibility to choose what you want on your audio CD using
your favorite audio player. This is in some cases a lot more convenient
than using the command line or graphical file manager. Just think about
creating a CD for a party or some other special event.


Fabian

Re: [Bashburn-info] 2nd try: I have a bash compatibility question (fwd)

[Markus K. <mar...@on...>]

Steven W. Orr wrote:
> ---------- Forwarded message ----------
> Date: Fri, 19 Sep 2008 16:48:25
> From: Steven W. Orr <st...@sy...>
> To: bashburn <Bas...@li...>
> Subject: I have a bash compatibility question
>
> What version of bash do we support? I run 3.0 here at home (currently) and at 
> work I happen to have 3.2. Do we have to support version 2 or are my 
> presumptions about 3 ok to be making?
>
>   
Hm, Steven have you a special reason why we should support bash >= 3.0 ?
I first thought we should support bash versions which are older than 3.0 
if we have no special reason. But then I searched and found this:

Bash-3.0 contained the following new features:

o Features to support the bash debugger have been implemented, and there
  is a new `extdebug' option to turn the non-default options on

o HISTCONTROL is now a colon-separated list of options and has been
  extended with a new `erasedups' option that will result in only one
  copy of a command being kept in the history list

o Brace expansion has been extended with a new {x..y} form, producing
  sequences of digits or characters

o Timestamps are now kept with history entries, with an option to save
  and restore them from the history file; there is a new HISTTIMEFORMAT
  variable describing how to display the timestamps when listing history
  entries

o The `[[' command can now perform extended regular expression (egrep-like)
  matching, with matched subexpressions placed in the BASH_REMATCH array
  variable

o A new `pipefail' option causes a pipeline to return a failure status if
  any command in it fails

o The `jobs', `kill', and `wait' builtins now accept job control notation
  in their arguments even if job control is not enabled

o The `gettext' package and libintl have been integrated, and the shell
  messages may be translated into other languages


So, since we want to use gettext (in bashburn version 3) we have to use 
bash version >= 3.0. Or am I wrong?

By the way - what does everyone think - should we use unicode (UTF8) for 
encoding the translations in bashburn 3?
This also means we have to switch console to unicode ("unicode_start")?

Markus

Re: [Bashburn-info] trunk: Remove xmmsread.sh?

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

On Sat, 20 Sep 2008 19:59:18 +0100
Nick Warne <ni...@li...> wrote:

> On Sat, 20 Sep 2008 15:31:20 +0200
> Anders Lindén <and...@gm...> wrote:
> 
> > I've been thinking about this, since XMMS is not developed anymore,
> > is there really a reason to keep the XMMS playlist burning
> > functionality?
> > 
> > Do people really use it? I suppose we could change it into "Burn
> > M3U-file" if people really want something like that. Thoughts?
> 
> Seeing as I do not get any mails posted to the list 'posted' at the
> moment, please forward.
> 
> I think Audacious has superseded xmms (was/is a fork?)... whether they
> use the same file extensions, I do not know.  It could be just a case
> of tweaking a few names here and there to keep the similar
> functionality.
> 
> Nick

Bugger me.  It was sent and received.

:-D

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] trunk: Remove xmmsread.sh?

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

On Sat, 20 Sep 2008 15:31:20 +0200
Anders Lindén <and...@gm...> wrote:

> I've been thinking about this, since XMMS is not developed anymore, is
> there really a reason to keep the XMMS playlist burning functionality?
> 
> Do people really use it? I suppose we could change it into "Burn
> M3U-file" if people really want something like that. Thoughts?

Seeing as I do not get any mails posted to the list 'posted' at the
moment, please forward.

I think Audacious has superseded xmms (was/is a fork?)... whether they
use the same file extensions, I do not know.  It could be just a case of
tweaking a few names here and there to keep the similar functionality.

Nick
-- 
Free Software Foundation Associate Member 5508

[Bashburn-info] trunk: Remove xmmsread.sh?

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

I've been thinking about this, since XMMS is not developed anymore, is
there really a reason to keep the XMMS playlist burning functionality?

Do people really use it? I suppose we could change it into "Burn
M3U-file" if people really want something like that. Thoughts?
-- 
Anders Lindén
http://bashburn.sf.net

Re: [Bashburn-info] From Nick: Fw: A few issues (fwd)

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

On Sat, 20 Sep 2008 13:03:51 +0200
Anders Lindén <and...@gm...> wrote:

> (Do not cd into trunk or release)  

Ah!  That was it.  I was running svn log in the branch.  At top level it
is all there.

Thanks!

Nick
-- 
Free Software Foundation Associate Member 5508

[Bashburn-info] New mail addy

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

OK, I have swapped my subscription to my own mail server now, as I
sent a few mails that never got delivered - I don't know why.

Strange thing was when I cancelled my ISP mail address, I got a bounce
from sourceforge saying my message will be viewed by a moderator as I
am not subscribed.

So the lost messages are in a queue somewhere waiting...

Anyway, I now subscribe from my mail server here at home.

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] 2nd try: I have a bash compatibility question (fwd)

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

On Sat, 20 Sep 2008 13:06:37 +0200
Anders Lindén <and...@gm...> wrote:

> I say version 3 is so common now that we can focus on supporting just
> that version. Any newer distro has version 3 included so there
> shouldn't be any problems.
> 
> Anyone disagree?
> 
> 
> On Sat, 2008-09-20 at 06:45 -0400, Steven W. Orr wrote:
> > ---------- Forwarded message ----------
> > Date: Fri, 19 Sep 2008 16:48:25
> > From: Steven W. Orr <st...@sy...>
> > To: bashburn <Bas...@li...>
> > Subject: I have a bash compatibility question
> > 
> > What version of bash do we support? I run 3.0 here at home
> > (currently) and at work I happen to have 3.2. Do we have to support
> > version 2 or are my presumptions about 3 ok to be making?
> > 

Nope, I think 3.xx.xx has been out a while now (2005 ?).

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] 2nd try: I have a bash compatibility question (fwd)

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

I say version 3 is so common now that we can focus on supporting just
that version. Any newer distro has version 3 included so there shouldn't
be any problems.

Anyone disagree?


On Sat, 2008-09-20 at 06:45 -0400, Steven W. Orr wrote:
> ---------- Forwarded message ----------
> Date: Fri, 19 Sep 2008 16:48:25
> From: Steven W. Orr <st...@sy...>
> To: bashburn <Bas...@li...>
> Subject: I have a bash compatibility question
> 
> What version of bash do we support? I run 3.0 here at home (currently) and at 
> work I happen to have 3.2. Do we have to support version 2 or are my 
> presumptions about 3 ok to be making?
> 
-- 
Anders Lindén
http://bashburn.sf.net

Re: [Bashburn-info] From Nick: Fw: A few issues (fwd)

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

Do you mean the history log for the entire project from when the svn
account was created? In that case, checkout the entire svn repo (That
is, run 
svn co https://svn.inf.sgsp.edu.pl/svn/bashburn)
and in the created directory (Do not cd into trunk or release) just run
svn log. 

> Secondly, for Anders perhaps.
> 
> On the new branches, if I do an 'svn log', I can only see log history
> for since the new branches was formed?  Ideas how to get the full
> history log back?
> 
> Nick
> -- 
> Free Software Foundation Associate Member 5508
> 
--  
Anders Lindén
http://bashburn.sf.net

[Bashburn-info] 2nd try: I have a bash compatibility question (fwd)

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

---------- Forwarded message ----------
Date: Fri, 19 Sep 2008 16:48:25
From: Steven W. Orr <st...@sy...>
To: bashburn <Bas...@li...>
Subject: I have a bash compatibility question

What version of bash do we support? I run 3.0 here at home (currently) and at 
work I happen to have 3.2. Do we have to support version 2 or are my 
presumptions about 3 ok to be making?

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