bashburn-info — BashBurn mailing list

Re: [Bashburn-info] Some more changes coming at you.

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

Tried out the latest revision and there are a few things I want to report:

* Header text is not printed. (When exiting the word BashBurn is not
printed either, so the exit message says "Thank you for using
<blank>..."

* The prompt still disappears if you enter a number, do not press
enter but backspace instead.

* The menus act a little strangely. It seems that if you at a menu at
the prompt just press enter without first entering a number, you are
sent to the first entry of the menu. For instance at the main menu you
are sent to the audio menu and at the define data menu you are sent to
the shell where you copy/link data. Correct response should be to show
a message telling the user to enter a number.

* Trying to burn audio files shows the error message:
"/opt/BashBurn/burning/burning.sh: line 41: return: check_for: numeric
argument required" though I can't see why that message would pop up
since a number is returned.

That's all for now. I'll return with more findings later (If I find
any that is...).



On Fri, Aug 29, 2008 at 4:17 PM, Steven W. Orr <st...@sy...> wrote:
> On Friday, Aug 29th 2008 at 07:50 -0000, quoth Nick Warne:
>
> =>On Thu, 28 Aug 2008 22:44:29 -0400 (EDT)
> =>"Steven W. Orr" <st...@sy...> wrote:
> =>
> =>
> =>> Guys, PLEASE look at what I've done. I'm getting lonely here and I
> =>> need you guys to keep me honest. I never make any misteaks but
> =>> there's this thing called Murphy's Ultimate corollary: If it could
> =>> have gone wrong earlier and it didn't, then it ultimately would have
> =>> been beneficial for it to have.
> =>
> =>Steve,
> =>
> =>I have recently got a new box (AMD64) and have been busy transferring
> =>data and stuff the last 14 days or so.
> =>
> =>I think this will be a good time to get latest svn BB and test it out,
> =>as I have yet to set up the burner on this thing.
> =>
> =>Stay tuned...
> =>
> =>Nick
> =>P.S. my trouble is I maybe use the burner once or twice a year, so
> =>never really can test, if you see what I mean.
>
> I'm thinking in terms of functional testing but I'm also thinking in terms
> of code review. If people can, please look at the code and see if you can
> find anything to discuss or if you see anything suspicious.
>
> --
> 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
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bashburn-info mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashburn-info
>



-- 
Anders Lindén

http://bashburn.sf.net

Re: [Bashburn-info] Some more changes coming at you.

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

On Friday, Aug 29th 2008 at 07:50 -0000, quoth Nick Warne:

=>On Thu, 28 Aug 2008 22:44:29 -0400 (EDT)
=>"Steven W. Orr" <st...@sy...> wrote:
=>
=>
=>> Guys, PLEASE look at what I've done. I'm getting lonely here and I
=>> need you guys to keep me honest. I never make any misteaks but
=>> there's this thing called Murphy's Ultimate corollary: If it could
=>> have gone wrong earlier and it didn't, then it ultimately would have
=>> been beneficial for it to have.
=>
=>Steve,
=>
=>I have recently got a new box (AMD64) and have been busy transferring
=>data and stuff the last 14 days or so.
=>
=>I think this will be a good time to get latest svn BB and test it out,
=>as I have yet to set up the burner on this thing.
=>
=>Stay tuned...
=>
=>Nick
=>P.S. my trouble is I maybe use the burner once or twice a year, so
=>never really can test, if you see what I mean.

I'm thinking in terms of functional testing but I'm also thinking in terms 
of code review. If people can, please look at the code and see if you can 
find anything to discuss or if you see anything suspicious.

-- 
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] Some more changes coming at you.

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

On Thu, 28 Aug 2008 22:44:29 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:


> Guys, PLEASE look at what I've done. I'm getting lonely here and I
> need you guys to keep me honest. I never make any misteaks but
> there's this thing called Murphy's Ultimate corollary: If it could
> have gone wrong earlier and it didn't, then it ultimately would have
> been beneficial for it to have.

Steve,

I have recently got a new box (AMD64) and have been busy transferring
data and stuff the last 14 days or so.

I think this will be a good time to get latest svn BB and test it out,
as I have yet to set up the burner on this thing.

Stay tuned...

Nick
P.S. my trouble is I maybe use the burner once or twice a year, so
never really can test, if you see what I mean.
-- 
Free Software Foundation Associate Member 5508

[Bashburn-info] Some more changes coming at you.

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

Lots of little cleanup stuff.

Lots more reduction in the number of processes that get created.

Henceforth and forthwith, all local variables should be lower case. All 
global variables should be uppercase. This is a *very* old trick I learned 
on an old and now very defunct operating system that required it.

I'm finding lots of global variables that are being set when the simple 
return value of a function could suffice.

I'm finding a few places where a global variable is set unconditionally 
and then tested later to see if something should be done. All ripped out.

More case insensitive stuff ripped out.

All of the read commands are now read -e. Anders, I was not able to 
reproduce your problem that you earlier described: " enter a number and 
press backspace, the prompt gets deleted". If you still see the problem, I 
will need more explicit info on how to reproduce.

I fixed the menu header problem.

is_dir_empty is now actually used all the places where it should have been 
before. Also, it is now greatly simplified.

delete_data had an interesting idea
while true
do
     read soemthing
     if something
     then
        do something
        break
     else
        do something else
        break
     fi
done

instead, how about

read soemthing
if something
then
    do something
else
    do something else
fi

Look Ma! No loops!

Here's a good one:
echo $(du -shL ${BBBURNDIR}) | cut -d ' ' -f 1
becomes
du -shL ${BBBURNDIR} | cut -d $'\t' -f 1

break or continue is wrong unless you're actually in a loop!

I see a number of things like this:

if something
then
     do something
     wait for enter
else
    do something else
    wait for enter
fi

I factored out the wait for enter. In some cases it was slightly dramatic.

Sombody should please look at what I did in audiofunc.sh in named. The 
comment says

 	    # If nothing is entered at the prompt then exit loop.
 	    continue

I assumed the comment was wrong and not the code. It's now restructured.

Here's a good one:
if [[ "$answer" == y ]]
then
     return 0
else
     return 1
fi
is now

[[ "$answer" == y ]]

Remember that status is always equal to the last thing you did.

in xmmsread, I broke out a small bit of awk magic and saved a process:

     done < <(grep -s [Mm][Pp]3 "${FILE}" | grep -v EXTINF)
vs
     done < <(awk 'BEGIN{IGNORECASE=1} /mp3/ && !/EXTINF/' "${file}")

Guys, PLEASE look at what I've done. I'm getting lonely here and I need 
you guys to keep me honest. I never make any misteaks but there's this 
thing called Murphy's Ultimate corollary: If it could have gone wrong 
earlier and it didn't, then it ultimately would have been beneficial for 
it to 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

Re: [Bashburn-info] Small annoyances

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

On Thursday, Aug 28th 2008 at 13:56 -0000, quoth Anders Lind?n:

=>While I haven't had time to go through what's been changed in any
=>deeper depth, I quickly noticed two small things that needs to be
=>fixed.
=>First, after entering a menu and returning to the main menu, it seems
=>the print header function is not run. The main menu shows up but under
=>the previous menu and without a header.
=>Second, if you at a menu enter a number and press backspace, the
=>prompt gets deleted. It still works but for some reason the prompt
=>disappears after backspace is pressed.

The first one sounds easy. Tonight.

I'll look at the 2nd one too. I suspect not all of the reads got a -e 
added to 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

[Bashburn-info] Small annoyances

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

While I haven't had time to go through what's been changed in any
deeper depth, I quickly noticed two small things that needs to be
fixed.
First, after entering a menu and returning to the main menu, it seems
the print header function is not run. The main menu shows up but under
the previous menu and without a header.
Second, if you at a menu enter a number and press backspace, the
prompt gets deleted. It still works but for some reason the prompt
disappears after backspace is pressed.



-- 
Anders Lindén

http://bashburn.sf.net

[Bashburn-info] Configure seems to be sort of working again.

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

Some notes before bedtime:

* Configure seems to be sort of working again but there's more to go. I 
still wanted to check it in because 1. It's better than it was and 2 I'm 
terrified of people stomping on me and making me do horrible merges. :-(

* Why does the configure menu have different actions than the advanced 
menu?

* Why do neither menus have a revert option? We have apply (which means 
write it to the config) and default (which means restore to a factory 
value, something that I suspect no one would ever want). I feel like it's 
pretty clumsy.

* There's a new configuremenu in define_global_menus:
     # Define the menu array entries. Colon is the seperator.
     # Field 1 is always the the prompt.
     # Field 2 is always the action if there's a match.
     # If field three exists then it is the current value to be displayed.
     # If there are 6 fields (i.e. $# == 6) then $6 is the name of a 
seperator
     # and no number will be displayed.
I'm not sure if I like it yet. Some of it doesn't look very elegant. :-( I 
usually work on the principle that if it doesn't look elegant then it's 
probably going to break.

* One complaint is that when you change the language, it doesn't "take" 
until you restart. That is almost correct. Actually, some of it does take 
but not any of the stuff that's in the current stack of execution at the 
time that it gets re-sourced. I have a couple of ideas on how to deal with 
that, OTOH, it might be legit to say that you have to exit and restart, or 
even something like

echo 'Dude bb will now restart'
exec bashburn

It's a side affect of the fact that we are no longer starting up reams of 
subprocesses. So, even if we re-source in all of the new language files, 
we're doing it from the context of running inside BashBurn.sh and 
configure.sh

Guten Nacht aller seits. Schlaf well ins Bettgestelle.

-- 
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'd like to propose new verbose functionality

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

On Wednesday, Aug 27th 2008 at 19:23 -0000, quoth Markus Kollmar:

=>Steven W. Orr wrote:

=>
=>> BTW, I wish more people would read TAOUP.
=>> 
=>>   
=>Yes, it is a really great book. It opened my eyes and shows the beauty of
=>unix. Or to see why there is more Unix nature in one line of shell script than
=>there is in ten thousand lines of C.

I don't know that I'd go that far, but in my mind the book articulated a 
lot that I had never expressed for myself but I had known for a long time.

-- 
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'd like to propose new verbose functionality

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

Steven W. Orr wrote:
> On Tuesday, Aug 26th 2008 at 17:10 -0000, quoth Markus Kollmar:
>
> =>Steven W. Orr wrote:
> =>> On Tuesday, Aug 26th 2008 at 13:39 -0000, quoth Anders Lind?n:
> =>> 
> =>> =>> Also, I think it makes more sense for the information to go to the
> =>> screen
> =>> =>> so the user gets feedback at the time that he executes something. Trying
> =>> =>> to go to a logfile *after* the session is over seems to defeat the
> =>> purpose
> =>> =>> of learning what's happening while it's happening.
> =>> =>>
> =>> =>True, but wouldn't it also be a good idea to have a log file that
> =>> =>people can just send to us incase something goes wrong?
> =>> 
> =>> We can do that too. :-)
> =>> 
> =>> If there are no objections, I'll stick it on the list and probably get to it
> =>> later tonight.
> =>> 
> =>>   
> =>Hm, my opinion is also to have a log-file. But there should be a option to
> =>deactivate it. Also the log file should not grow to big.
> =>
> =>Comment to "verbose functionality":
> =>The unix veterans told us that a programm should just do it's work and only be
> =>VERY verbose if something does not function right or the function fails or in
> =>case of an other error.
> =>
> =>So we read in the book "The Art Of Unix Programming" (Eric S. Raymond):
> =>
> =>"Go ahead and give your GUIs progress bars for long operations."
> =>
> =>"Your interface design as a whole should obey a Rule of Least Surprise, but
> =>the content of messages should obey a Rule of Most Surprise - be chatty only
> =>about things that deviate from what's normally expected."
> =>
> =>"If you want chatty progress messages for debugging purposes, disable them by
> =>default with a verbosity switch."
> =>
> =>So where do you think exactly more verbosity is needed?
> =>
> =>Markus Kollmar
>
> Markus, I took the liberty of answering you on the list. It really should 
> be part of the public discussion of the tool.
>   
That is ok Steven, that is what I wanted in fact!! ;-)  Ohhh - I have 
totally overlooked that my replying's to you have not reached all (the 
whole bashburn-list).

> I think verbosity is the wrong phrase to be using. There are lots of GUIs 
> out there that do lots of things. I categorize some GUIs (like BB as 
> wrappers for complex systems of commandline interfaces. For example, if I 
> was going to write a wrapper around The Dreaded find Command, I would want 
> to see the generated commands. Why? Because this is not about finding 
> files. It's about making it easier to run the find command.
>
> In the case of BashBurn, we're not talking about a new GUI interface that 
> reimplements what cdrecord + company already do. We're talking about a GUI 
> wrapper around a set of very complicated commandlines.
>
> I claim that the context of Raymond's quote is different. He's talking 
> about display of things like error messages, warning messages or even 
> informative messages that result from these either these operations or 
> from operations that are not even commandline based. I'm talking 
> about the (17?) commands themselves.
>
>   
Hmm, yes  Raymond surely talks also about commands like "cp" which need 
no messages about what they did. But since we have a more complicated 
programm, it would perhaps be helpful for the user to have messages 
which give him a little the feeling that basburn does nothing bad 
(messages he could disable anyway if he want).
> I very much like the idea of being able to turn on seeing the commandlines 
> that are generated as part of the regular output produced by the wrapper 
> (as opposed to the logfile). To see the generated errors that result is a 
> totally different discussion.
>
>   
Ok, yes so this commandlines would also have a little bit the function 
of a progress bar (one can see, what is going on and whether something 
stops).

> BTW, I wish more people would read TAOUP.
>
>   
Yes, it is a really great book. It opened my eyes and shows the beauty 
of unix. Or to see why there is more Unix nature in one line of shell 
script than there is in ten thousand lines of C.

:-)

Re: [Bashburn-info] I'd like to propose new verbose functionality

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

On Tuesday, Aug 26th 2008 at 17:10 -0000, quoth Markus Kollmar:

=>Steven W. Orr wrote:
=>> On Tuesday, Aug 26th 2008 at 13:39 -0000, quoth Anders Lind?n:
=>> 
=>> =>> Also, I think it makes more sense for the information to go to the
=>> screen
=>> =>> so the user gets feedback at the time that he executes something. Trying
=>> =>> to go to a logfile *after* the session is over seems to defeat the
=>> purpose
=>> =>> of learning what's happening while it's happening.
=>> =>>
=>> =>True, but wouldn't it also be a good idea to have a log file that
=>> =>people can just send to us incase something goes wrong?
=>> 
=>> We can do that too. :-)
=>> 
=>> If there are no objections, I'll stick it on the list and probably get to it
=>> later tonight.
=>> 
=>>   
=>Hm, my opinion is also to have a log-file. But there should be a option to
=>deactivate it. Also the log file should not grow to big.
=>
=>Comment to "verbose functionality":
=>The unix veterans told us that a programm should just do it's work and only be
=>VERY verbose if something does not function right or the function fails or in
=>case of an other error.
=>
=>So we read in the book "The Art Of Unix Programming" (Eric S. Raymond):
=>
=>"Go ahead and give your GUIs progress bars for long operations."
=>
=>"Your interface design as a whole should obey a Rule of Least Surprise, but
=>the content of messages should obey a Rule of Most Surprise - be chatty only
=>about things that deviate from what's normally expected."
=>
=>"If you want chatty progress messages for debugging purposes, disable them by
=>default with a verbosity switch."
=>
=>So where do you think exactly more verbosity is needed?
=>
=>Markus Kollmar

Markus, I took the liberty of answering you on the list. It really should 
be part of the public discussion of the tool.

I think verbosity is the wrong phrase to be using. There are lots of GUIs 
out there that do lots of things. I categorize some GUIs (like BB as 
wrappers for complex systems of commandline interfaces. For example, if I 
was going to write a wrapper around The Dreaded find Command, I would want 
to see the generated commands. Why? Because this is not about finding 
files. It's about making it easier to run the find command.

In the case of BashBurn, we're not talking about a new GUI interface that 
reimplements what cdrecord + company already do. We're talking about a GUI 
wrapper around a set of very complicated commandlines.

I claim that the context of Raymond's quote is different. He's talking 
about display of things like error messages, warning messages or even 
informative messages that result from these either these operations or 
from operations that are not even commandline based. I'm talking 
about the (17?) commands themselves.

I very much like the idea of being able to turn on seeing the commandlines 
that are generated as part of the regular output produced by the wrapper 
(as opposed to the logfile). To see the generated errors that result is a 
totally different discussion.

BTW, I wish more people would read TAOUP.

-- 
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 added a new file:TBD

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

On Tuesday, Aug 26th 2008 at 16:16 -0000, quoth Markus Kollmar:

=>Steven W. Orr wrote:
=>> It's a place where people can add things they want to see get done. Tom
=>> Clancy said that if you don't write iot down then it never happened.
=>> 
=>> BTW, I have checked in a *lot* of changes that hits more than the menus. So
=>> far I haven't heard a peep out of anyone. Is anyone home? Do you hate what
=>> happened? Is my network connect still up? ;-)
=>> 
=>> 
=>>   
=>
=>Hi Steven, yes I am sure there are people at home. ;-)
=>But it happens that - like I - one can not be online every day, so I think you
=>just have to wait some time and I am sure that there will come some reaction.
=>
=>Yes, you have really good design ideas.
=>The TBD file is one. But we have already a TODO file. I think we should only
=>have one file named TODO. We should put the TBD contents in TODO, or not?
=>
=>By the way I have one major point which I think we should improve: After
=>configuring the language in bashburn menu, the new language appears only after
=>restarting bashburn.
=>
=>Markus Kollmar
=>

Can someone please explain to me why it is that I was staring at that 
directory and never saw the TODO file. It's official. I either getting 
stupid, senile or both. I'll fix both tonight too. :-)

-- 
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'd like to propose new verbose functionality

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

On Tuesday, Aug 26th 2008 at 13:39 -0000, quoth Anders Lind?n:

=>> Also, I think it makes more sense for the information to go to the screen
=>> so the user gets feedback at the time that he executes something. Trying
=>> to go to a logfile *after* the session is over seems to defeat the purpose
=>> of learning what's happening while it's happening.
=>>
=>True, but wouldn't it also be a good idea to have a log file that
=>people can just send to us incase something goes wrong?

We can do that too. :-)

If there are no objections, I'll stick it on the list and probably get to 
it later tonight.

-- 
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'd like to propose new verbose functionality

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

> Also, I think it makes more sense for the information to go to the screen
> so the user gets feedback at the time that he executes something. Trying
> to go to a logfile *after* the session is over seems to defeat the purpose
> of learning what's happening while it's happening.
>
True, but wouldn't it also be a good idea to have a log file that
people can just send to us incase something goes wrong?

> BTW, I'm only talking about those commands that are what bb is all about.
> I'm *not* talking about turning tracing on for the whole script.
>
Yeah that's what I figured, and I'm all for it as long as an option to
disable this functionality also exists.

> =>On Tue, Aug 26, 2008 at 5:21 PM, Steven W. Orr <st...@sy...> wrote:
> =>> The idea is that I detest GUIs that execute commandlines without telling
> =>> you what it's doing. For example, k3b is just doing the same thing (I
> =>> believe) that BB is doing; it runs cdrecord, mkisofs, etc, but I never
> =>> actually see what it's doing.
> =>>
> =>> Here at the company I work for, we use Perforce for our revision control.
> =>> There's a commandline interface and also a GUI available. The Perforce GUI
> =>> is nice because it has a little command window that tells you exactly what
> =>> it's doing at all times.
> =>>
> =>> I'd like to see BB do the same thing. Here are some options:
> =>>
> =>> * It always goes to a log file. We currently already write the date? to
> =>> $BBERRLOG. Alternatively it could just go to stdout or stderr.
> =>>
> =>> * We could add a -v option to the commandline to turn on this verbose
> =>> output.
> =>>
> =>> * We could have a command option to toggle verbose in the main menu.
> =>>
> =>> * We could make it a config option.
> =>>
> =>> Who likes this? Who dislikes it? Are any of the above options attractive?
> =>>
> =>> Don't think *how* it gets implemented. Think what you want it to do.
> =>>
>
> --
> 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
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bashburn-info mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashburn-info
>



-- 
Anders Lindén

http://bashburn.sf.net

Re: [Bashburn-info] I'd like to propose new verbose functionality

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

On Tuesday, Aug 26th 2008 at 13:24 -0000, quoth Anders Lind?n:

=>I'd prefer an option in the configure menu to turn on/off verbose
=>mode. Not all people want their programs spitting out tons of
=>information, but some of course do. Anyone else have suggestions?

Also, I think it makes more sense for the information to go to the screen 
so the user gets feedback at the time that he executes something. Trying 
to go to a logfile *after* the session is over seems to defeat the purpose 
of learning what's happening while it's happening.

BTW, I'm only talking about those commands that are what bb is all about. 
I'm *not* talking about turning tracing on for the whole script.

=>On Tue, Aug 26, 2008 at 5:21 PM, Steven W. Orr <st...@sy...> wrote:
=>> The idea is that I detest GUIs that execute commandlines without telling
=>> you what it's doing. For example, k3b is just doing the same thing (I
=>> believe) that BB is doing; it runs cdrecord, mkisofs, etc, but I never
=>> actually see what it's doing.
=>>
=>> Here at the company I work for, we use Perforce for our revision control.
=>> There's a commandline interface and also a GUI available. The Perforce GUI
=>> is nice because it has a little command window that tells you exactly what
=>> it's doing at all times.
=>>
=>> I'd like to see BB do the same thing. Here are some options:
=>>
=>> * It always goes to a log file. We currently already write the date? to
=>> $BBERRLOG. Alternatively it could just go to stdout or stderr.
=>>
=>> * We could add a -v option to the commandline to turn on this verbose
=>> output.
=>>
=>> * We could have a command option to toggle verbose in the main menu.
=>>
=>> * We could make it a config option.
=>>
=>> Who likes this? Who dislikes it? Are any of the above options attractive?
=>>
=>> Don't think *how* it gets implemented. Think what you want it to do.
=>>

-- 
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'd like to propose new verbose functionality

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

I'd prefer an option in the configure menu to turn on/off verbose
mode. Not all people want their programs spitting out tons of
information, but some of course do. Anyone else have suggestions?


On Tue, Aug 26, 2008 at 5:21 PM, Steven W. Orr <st...@sy...> wrote:
> The idea is that I detest GUIs that execute commandlines without telling
> you what it's doing. For example, k3b is just doing the same thing (I
> believe) that BB is doing; it runs cdrecord, mkisofs, etc, but I never
> actually see what it's doing.
>
> Here at the company I work for, we use Perforce for our revision control.
> There's a commandline interface and also a GUI available. The Perforce GUI
> is nice because it has a little command window that tells you exactly what
> it's doing at all times.
>
> I'd like to see BB do the same thing. Here are some options:
>
> * It always goes to a log file. We currently already write the date? to
> $BBERRLOG. Alternatively it could just go to stdout or stderr.
>
> * We could add a -v option to the commandline to turn on this verbose
> output.
>
> * We could have a command option to toggle verbose in the main menu.
>
> * We could make it a config option.
>
> Who likes this? Who dislikes it? Are any of the above options attractive?
>
> Don't think *how* it gets implemented. Think what you want it to do.
>
> --
> 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
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bashburn-info mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashburn-info
>



-- 
Anders Lindén

http://bashburn.sf.net

[Bashburn-info] I'd like to propose new verbose functionality

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

The idea is that I detest GUIs that execute commandlines without telling 
you what it's doing. For example, k3b is just doing the same thing (I 
believe) that BB is doing; it runs cdrecord, mkisofs, etc, but I never 
actually see what it's doing.

Here at the company I work for, we use Perforce for our revision control. 
There's a commandline interface and also a GUI available. The Perforce GUI 
is nice because it has a little command window that tells you exactly what 
it's doing at all times.

I'd like to see BB do the same thing. Here are some options:

* It always goes to a log file. We currently already write the date? to 
$BBERRLOG. Alternatively it could just go to stdout or stderr.

* We could add a -v option to the commandline to turn on this verbose 
output.

* We could have a command option to toggle verbose in the main menu.

* We could make it a config option.

Who likes this? Who dislikes it? Are any of the above options attractive?

Don't think *how* it gets implemented. Think what you want it to do.

-- 
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] I added a new file:TBD

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

It's a place where people can add things they want to see get done. Tom 
Clancy said that if you don't write iot down then it never happened.

BTW, I have checked in a *lot* of changes that hits more than the menus. 
So far I haven't heard a peep out of anyone. Is anyone home? Do you hate 
what happened? Is my network connect still 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] In audiofunc.sh, problem wuth encode_filter

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

encode_filter only does something if ENCODEFILTER is not null.

It is never set.

-- 
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] In loopback.sh

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

There's a call to cleanup and I believe cleanup is not defined.

loopback_cleanup is defined but that's a seperate issue.

Anyone?

-- 
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] In burning.sh in pipeline_burning...

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

Why was FIFOLST initialized to a semicolon?

Is this a misteak?

-- 
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] Fixing burning/burning.sh

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

pipeline_burning used to check is existing was equal to positive instead 
of affirmative. I ripped the whole thing out.

Also, I pulled all of the exit calls.


Let me know if you find problems.

-- 
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] New menu system is now checked in.

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

It seems to work. Let me know what bad things you find. You'll notice that 
the configure menu is left intact. I did that because it's special with 
the extra items at the end. I'll deal wit hthat one seperately via options 
to bbmenu.

The install script still has a lot of cruft in it but some of it was 
looked at.

You'll notice that the menu definitions are all done as global variables 
in something called define_global_menus().

The invocation of the action in bbmenu ended up requiring eval because of 
the action potentially having multiple words.

Everyone should be *very* careful WRT quoting in bbmenu. Almost every 
single quote, double quote, and lack of any quote mark is very deliberate.

One thing that needs to be looked at are exits. Because bb is no longer 
multiple processes, a call to exit will no longer terminate the sub 
process; instead it will terminate all of bb.

Let me know if you have any questions.

-- 
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] Random notes

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

Option 6 of the main menu:
 	    configure
             # And in case we changed any options, read in vars again
 	    bb_parse_config

No need to re-call bb_parse_config. Removed.


-- 
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] New menu subsystem.

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

On Friday, Aug 22nd 2008 at 21:16 -0000, quoth Markus Kollmar:

=>Steven W. Orr wrote:
=>> As I mentioned the other day, I really hate the way we currently draw menus.
=>> I wrote a module (bbmenu.sh) which takes an array of descriptors as an
=>> argument and then just runs with it. All of the menu code is just duped
=>> everywhere for every menu, so this just seemed like a no brainer. It will
=>> reduce the size of bb quite significantly.
=>> 
=>> Here's my plan: I can't do this all in one day, and since we don't currently
=>> have a devel branch seperate from a main trunk, it's really not going to be
=>> possible to check in all of the changes atomically without making extra
=>> work. Therefore, if I promise to get it all done by the end of the weekend,
=>> will that be ok with everyone? All this means is that the tree *may* be
=>> broken until I finish. I will check in bbmenu.sh tonight (which won't hurt
=>> anything since it's not yet referenced. It will need to be tweaked further,
=>> but you'll be able to see what I'm doing.
=>> 
=>> For taste, in BashBurn.sh where the MAIN menu is posted, it will eventually
=>> end up with this:
=>> 
=>> bbmenu=( \
=>> "$bb_menu_1:audio_menu" \
=>> "$bb_menu_2:data_menu" \
=>> "$bb_menu_3:iso" \
=>> "$bb_menu_4:bincue" \
=>> "$bb_menu_5:multi" \
=>> "$bb_menu_6:configure_menu" \
=>> "$bb_menu_7:check_path" \
=>> "$bb_menu_8:datadefine" \
=>> "$bb_menu_9:bbexit" )
=>> 
=>> and the whole menu will happen by simply saying:
=>> 
=>> menu MAIN "${bbmenu[@]}"
=>> 
=>> 
=>>   
=>
=>Well, the idea is nice to have one call to create and execute menu's. So we
=>have a single point to look on in case of menue debugging or changing the look
=>of all bashburn-menu's easily.
=>But it seems that this will be a bigger cut - since you must provide for every
=>menue point a function?

Almost correct. Things like

	44)
	    doodis
	    doodat
	    ;;

don't *have* to be a new function. You could just as easily say something 
like:

	doomenu=( \
		....
	    "$doomenu_44:{ doodis; doodat; }" \
	        ... \
	 )

but either way, it seems like a fair tradeoff.

You do however raise an interesting point. Let's go further with it.
bbmenu=( \
   "$bb_menu_1:audio_menu" \
   "$bb_menu_2:data_menu" \
   "$bb_menu_3:iso" \
   "$bb_menu_4:bincue" \
   "$bb_menu_5:multi" \
   "$bb_menu_6:configure_menu" \
   "$bb_menu_7:check_path" \
   "$bb_menu_8:datadefine" \
   "$bb_menu_9:bbexit" )

could be 
typeset -ra bbaction=(audio_menu \
	 data_menu \
	 iso \
	 bincue \
	 multi \
	 configure_menu \
	 check_path \
	 datadefine \
	 bbexit )
followed by
for (( ii=1; ii < bbsize; ii++ ))
do
    bbmenu[ii]="bb_menu_${ii}:${bbaction[ii]}"
done
menu MAIN "${bbmenu[@]}"

I'm just exploring so you can see some of the types of constructs
that are available, (And yes I know that as a wrote it, the subscripts
are off. Gimme a break, it's late here.;-)>



=>
=>Markus Kollmar
=>
=>

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

[Bashburn-info] New menu subsystem.

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

As I mentioned the other day, I really hate the way we currently draw 
menus. I wrote a module (bbmenu.sh) which takes an array of descriptors as 
an argument and then just runs with it. All of the menu code is just 
duped everywhere for every menu, so this just seemed like a no brainer. It 
will reduce the size of bb quite significantly.

Here's my plan: I can't do this all in one day, and since we don't 
currently have a devel branch seperate from a main trunk, it's really not 
going to be possible to check in all of the changes atomically without 
making extra work. Therefore, if I promise to get it all done by the end 
of the weekend, will that be ok with everyone? All this means is that the 
tree *may* be broken until I finish. I will check in bbmenu.sh tonight 
(which won't hurt anything since it's not yet referenced. It will need to 
be tweaked further, but you'll be able to see what I'm doing.

For taste, in BashBurn.sh where the MAIN menu is posted, it will 
eventually end up with this:

bbmenu=( \
"$bb_menu_1:audio_menu" \
"$bb_menu_2:data_menu" \
"$bb_menu_3:iso" \
"$bb_menu_4:bincue" \
"$bb_menu_5:multi" \
"$bb_menu_6:configure_menu" \
"$bb_menu_7:check_path" \
"$bb_menu_8:datadefine" \
"$bb_menu_9:bbexit" )

and the whole menu will happen by simply saying:

menu MAIN "${bbmenu[@]}"


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