Thread: [Bashburn-info] I'd like to propose new verbose functionality
Brought to you by:
bashburn
Menu
▾
▴
bashburn-info
|
From: Steven W. O. <st...@sy...> - 2008-08-26 15:21:35
|
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 |
|
From: A. L. <and...@gm...> - 2008-08-26 17:24:18
|
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 |
|
From: Steven W. O. <st...@sy...> - 2008-08-26 17:35:42
|
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 |
|
From: A. L. <and...@gm...> - 2008-08-26 17:39:31
|
> 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 |
|
From: Steven W. O. <st...@sy...> - 2008-08-26 17:50:50
|
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 |
|
From: Steven W. O. <st...@sy...> - 2008-08-27 02:15:04
|
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 |
|
From: Markus K. <mar...@on...> - 2008-08-27 23:19:30
|
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. :-) |
|
From: Steven W. O. <st...@sy...> - 2008-08-28 00:12:46
|
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 |
Thanks for helping keep SourceForge clean.
X