Thread: [Bashburn-info] Some language and user-interface things
Brought to you by:
bashburn
Menu
▾
▴
bashburn-info
|
From: Markus K. <mar...@on...> - 2008-10-06 12:24:20
|
By testing/debugging german translation i found some things (which also
affect the other languages):
--> 1. Seems we can remove following variables from language files?:
bb_conf_menu_root="Root Directory"
bb_conf_def_2="(BBROOTDIR has *no* default - you have to change it!)"
bb_conf_ch_root="This options specifies the location of the BashBurn
scripts.
You should really have no reason to change this value,
only do so if you know what you're doing.
The current setting is: ${BBOPTIONCOLOR}${BBROOTDIR}${BBCOLOROFF}.
${bb_conf_cancel_quote}"
--> 2. The option
bb_conf_ch_dropts=\
"This option specifies the driver specific options used
when burning a disc. An examples is
${BBOPTIONCOLOR}burnfree${BBCOLOROFF} for
avoiding buffer underruns. You can specify several options by separating
them with a comma. This option is non-mandatory and can be skipped.
Current setting is: ${BBOPTIONCOLOR}${BBOPT_ONE}${BBCOLOROFF}, and below
is a list
of possible options. ${bb_conf_cancel_quote}"
says that below will occur a list with possible driver options, but
there is none? Has it to be hardcoded in lang-files or is there a
command we can get this options?
--> 3. in file "configure.sh":
---SNIP
config_default()
{
pretty_top
top_info_line
get_really_sure && return
configure_changes=( \
'BBISCONF|0' \
'BBCDWRITER|<Change me>' \
'BBCDROM|<Change me>' \
'BBCDMNT|<Change me>' \
'BBSPEED|-1' \
'BBBLANKING|fast' \
'BBNUMDEV|1' \
'BBBURNDIR|/tmp/burn' \
'BBFIFODIR|/tmp' \
'BBDESCRIPTION|Burnt with BashBurn' \
'BBAUTHOR|<Change me>' \
'BBLABEL|BashBurn CD/DVD' \
'BBNORMALIZE|no' \
'BBOPT|ONE: ' \
'BBDELTEMPBURN|no' \
'BBOVERBURN|no' \
'BBBITRATE|192' \
'BBLANG|English' \
'BBDTAO|-tao' \
'BBPADDING|-pad' \
)
conf_set_aval "${configure_changes[@]}"
config_revert
# bb_parse_config
}
----SNIP
maybe
"'BBOPT|ONE: ' \" should become "'BBOPT_ONE:| ' \"
or Steven?
Markus
|
|
From: Nick W. <ni...@uk...> - 2008-10-06 12:49:16
|
On Mon, 06 Oct 2008 13:44:19 +0200
Markus Kollmar <mar...@on...> wrote:
> --> 3. in file "configure.sh":
>
> ---SNIP
> config_default()
> {
> pretty_top
> top_info_line
> get_really_sure && return
> configure_changes=( \
> 'BBISCONF|0' \
> 'BBCDWRITER|<Change me>' \
> 'BBCDROM|<Change me>' \
> 'BBCDMNT|<Change me>' \
> 'BBSPEED|-1' \
> 'BBBLANKING|fast' \
> 'BBNUMDEV|1' \
> 'BBBURNDIR|/tmp/burn' \
> 'BBFIFODIR|/tmp' \
> 'BBDESCRIPTION|Burnt with BashBurn' \
> 'BBAUTHOR|<Change me>' \
> 'BBLABEL|BashBurn CD/DVD' \
> 'BBNORMALIZE|no' \
> 'BBOPT|ONE: ' \
> 'BBDELTEMPBURN|no' \
> 'BBOVERBURN|no' \
> 'BBBITRATE|192' \
> 'BBLANG|English' \
> 'BBDTAO|-tao' \
> 'BBPADDING|-pad' \
> )
> conf_set_aval "${configure_changes[@]}"
> config_revert
> # bb_parse_config
> }
>
> ----SNIP
>
> maybe
> "'BBOPT|ONE: ' \" should become "'BBOPT_ONE:| ' \"
Dead right - well spotted. I have fixed this up and committed.
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Nick W. <ni...@uk...> - 2008-10-06 13:08:07
|
On Mon, 6 Oct 2008 13:46:33 +0100
Nick Warne <ni...@uk...> wrote:
> On Mon, 06 Oct 2008 13:44:19 +0200
> Markus Kollmar <mar...@on...> wrote:
>
> > --> 3. in file "configure.sh":
> >
> > ---SNIP
> > config_default()
> > {
> > pretty_top
> > top_info_line
> > get_really_sure && return
> > configure_changes=( \
> > 'BBISCONF|0' \
> > 'BBCDWRITER|<Change me>' \
> > 'BBCDROM|<Change me>' \
> > 'BBCDMNT|<Change me>' \
> > 'BBSPEED|-1' \
> > 'BBBLANKING|fast' \
> > 'BBNUMDEV|1' \
> > 'BBBURNDIR|/tmp/burn' \
> > 'BBFIFODIR|/tmp' \
> > 'BBDESCRIPTION|Burnt with BashBurn' \
> > 'BBAUTHOR|<Change me>' \
> > 'BBLABEL|BashBurn CD/DVD' \
> > 'BBNORMALIZE|no' \
> > 'BBOPT|ONE: ' \
> > 'BBDELTEMPBURN|no' \
> > 'BBOVERBURN|no' \
> > 'BBBITRATE|192' \
> > 'BBLANG|English' \
> > 'BBDTAO|-tao' \
> > 'BBPADDING|-pad' \
> > )
> > conf_set_aval "${configure_changes[@]}"
> > config_revert
> > # bb_parse_config
> > }
> >
> > ----SNIP
> >
> > maybe
> > "'BBOPT|ONE: ' \" should become "'BBOPT_ONE:| ' \"
>
> Dead right - well spotted. I have fixed this up and committed.
OK, do a svn update. BBOPT_ONE doesn't mean a lot, so I have changed
this to be what it is BBDRIVEROPT.
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Nick W. <ni...@uk...> - 2008-10-06 13:08:40
|
On Mon, 6 Oct 2008 14:05:18 +0100
Nick Warne <ni...@uk...> wrote:
> On Mon, 6 Oct 2008 13:46:33 +0100
> Nick Warne <ni...@uk...> wrote:
>
> > On Mon, 06 Oct 2008 13:44:19 +0200
> > Markus Kollmar <mar...@on...> wrote:
> >
> > > --> 3. in file "configure.sh":
> > >
> > > ---SNIP
> > > config_default()
> > > {
> > > pretty_top
> > > top_info_line
> > > get_really_sure && return
> > > configure_changes=( \
> > > 'BBISCONF|0' \
> > > 'BBCDWRITER|<Change me>' \
> > > 'BBCDROM|<Change me>' \
> > > 'BBCDMNT|<Change me>' \
> > > 'BBSPEED|-1' \
> > > 'BBBLANKING|fast' \
> > > 'BBNUMDEV|1' \
> > > 'BBBURNDIR|/tmp/burn' \
> > > 'BBFIFODIR|/tmp' \
> > > 'BBDESCRIPTION|Burnt with BashBurn' \
> > > 'BBAUTHOR|<Change me>' \
> > > 'BBLABEL|BashBurn CD/DVD' \
> > > 'BBNORMALIZE|no' \
> > > 'BBOPT|ONE: ' \
> > > 'BBDELTEMPBURN|no' \
> > > 'BBOVERBURN|no' \
> > > 'BBBITRATE|192' \
> > > 'BBLANG|English' \
> > > 'BBDTAO|-tao' \
> > > 'BBPADDING|-pad' \
> > > )
> > > conf_set_aval "${configure_changes[@]}"
> > > config_revert
> > > # bb_parse_config
> > > }
> > >
> > > ----SNIP
> > >
> > > maybe
> > > "'BBOPT|ONE: ' \" should become "'BBOPT_ONE:| ' \"
> >
> > Dead right - well spotted. I have fixed this up and committed.
>
> OK, do a svn update. BBOPT_ONE doesn't mean a lot, so I have changed
> this to be what it is BBDRIVEROPT.
Oh, forgot. After pulling this in, start BB, go to configure and just
'apply changes' - this will update your .bashburnrc file with the
renmaed $VAR
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Nick W. <ni...@uk...> - 2008-10-06 13:31:34
|
On Mon, 06 Oct 2008 13:44:19 +0200
Markus Kollmar <mar...@on...> wrote:
> --> 2. The option
>
> bb_conf_ch_dropts=\
> "This option specifies the driver specific options used
> when burning a disc. An examples is
> ${BBOPTIONCOLOR}burnfree${BBCOLOROFF} for
> avoiding buffer underruns. You can specify several options by
> separating them with a comma. This option is non-mandatory and can be
> skipped. Current setting is:
> ${BBOPTIONCOLOR}${BBOPT_ONE}${BBCOLOROFF}, and below is a list
> of possible options. ${bb_conf_cancel_quote}"
>
> says that below will occur a list with possible driver options, but
> there is none? Has it to be hardcoded in lang-files or is there a
> command we can get this options?
OK, I fixed this up too - cool feature!
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Markus K. <mar...@on...> - 2008-10-06 14:56:20
|
Nick Warne wrote:
> On Mon, 06 Oct 2008 15:57:45 +0200
> Markus Kollmar <mar...@on...> wrote:
>
>
>> Nick Warne wrote:
>>
>>> On Mon, 06 Oct 2008 13:44:19 +0200
>>> Markus Kollmar <mar...@on...> wrote:
>>>
>>>
>>>
>>>
>>>> --> 2. The option
>>>>
>>>> bb_conf_ch_dropts=\
>>>> "This option specifies the driver specific options used
>>>> when burning a disc. An examples is
>>>> ${BBOPTIONCOLOR}burnfree${BBCOLOROFF} for
>>>> avoiding buffer underruns. You can specify several options by
>>>> separating them with a comma. This option is non-mandatory and can
>>>> be skipped. Current setting is:
>>>> ${BBOPTIONCOLOR}${BBOPT_ONE}${BBCOLOROFF}, and below is a list
>>>> of possible options. ${bb_conf_cancel_quote}"
>>>>
>>>> says that below will occur a list with possible driver options,
>>>> but there is none? Has it to be hardcoded in lang-files or is
>>>> there a command we can get this options?
>>>>
>>>>
>>> OK, I fixed this up too - cool feature!
>>>
>>> Nick
>>>
>>>
>> Nick does this print some options on your screen?
>> I have tested it myself but i got no option list...
>>
>>
>
> Yes, works fine here. Have you svn update again since?
>
> Nick
>
Ok, sorry was my fault (not entered correct burning drive on my new
slackware system).
But we got the whole dump of the command - even in my case a warning
message, and not just the option list?
Markus
|
|
From: Nick W. <ni...@uk...> - 2008-10-06 18:58:21
|
On Mon, 06 Oct 2008 16:56:23 +0200
Markus Kollmar <mar...@on...> wrote:
> Nick Warne wrote:
> > On Mon, 06 Oct 2008 15:57:45 +0200
> > Markus Kollmar <mar...@on...> wrote:
> >
> >
> >> Nick Warne wrote:
> >>
> >>> On Mon, 06 Oct 2008 13:44:19 +0200
> >>> Markus Kollmar <mar...@on...> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>> --> 2. The option
> >>>>
> >>>> bb_conf_ch_dropts=\
> >>>> "This option specifies the driver specific options used
> >>>> when burning a disc. An examples is
> >>>> ${BBOPTIONCOLOR}burnfree${BBCOLOROFF} for
> >>>> avoiding buffer underruns. You can specify several options by
> >>>> separating them with a comma. This option is non-mandatory and
> >>>> can be skipped. Current setting is:
> >>>> ${BBOPTIONCOLOR}${BBOPT_ONE}${BBCOLOROFF}, and below is a list
> >>>> of possible options. ${bb_conf_cancel_quote}"
> >>>>
> >>>> says that below will occur a list with possible driver options,
> >>>> but there is none? Has it to be hardcoded in lang-files or is
> >>>> there a command we can get this options?
> >>>>
> >>>>
> >>> OK, I fixed this up too - cool feature!
> >>>
> >>> Nick
> >>>
> >>>
> >> Nick does this print some options on your screen?
> >> I have tested it myself but i got no option list...
> >>
> >>
> >
> > Yes, works fine here. Have you svn update again since?
> >
> > Nick
> >
> Ok, sorry was my fault (not entered correct burning drive on my new
> slackware system).
>
> But we got the whole dump of the command - even in my case a warning
> message, and not just the option list?
Markus,
I think that is how it used to work if I remember correctly. I did
read the cdrecord man page, but can't see any option to just extract
'options'.
I guess we could do some sort of grep magic on the output, but then as
we don't know what make/model/CD/DVD burners/drives have with all the
possible options returned, it would be an impossible job.
Also, if somebody is nerdy enough to use BashBurn, then I think the
return output will be no problem for the user :-)
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Nick W. <ni...@uk...> - 2008-10-06 19:24:32
|
On Mon, 06 Oct 2008 16:56:23 +0200 Markus Kollmar <mar...@on...> wrote: > Ok, sorry was my fault (not entered correct burning drive on my new > slackware system). Yes, I did test this with a stupid /dev/cdrom99 entry, and nothing gets reported. I will look at a doing check first to see if the drive is valid. Or perhaps the easiest option is to change the INFORMATION text to report if you do not see any output, then the valid entry for burner is incorrect. Slackware :-) Good man :-) Nick -- Free Software Foundation Associate Member 5508 |
|
From: Markus K. <mar...@on...> - 2008-10-06 20:56:42
|
Nick Warne schrieb: > On Mon, 06 Oct 2008 16:56:23 +0200 > Markus Kollmar <mar...@on...> wrote: > > >> Ok, sorry was my fault (not entered correct burning drive on my new >> slackware system). >> > > Yes, I did test this with a stupid /dev/cdrom99 entry, and nothing gets > reported. I will look at a doing check first to see if the drive is > valid. Or perhaps the easiest option is to change the INFORMATION text > to report if you do not see any output, then the valid entry for burner > is incorrect. > > Slackware :-) Good man :-) > > Nick > Hehe Nick. :-) Yes you are right, I think also it is much work to grep the output of the burner-option (since it seems not strongly formated and some part of output goes not to stdout I think.) And the users of bashburn - like you said - are mostly not totally new users of a command line tool (since they must - to define burn data with bashburn - have a minimal knowledge of standard bash commands like 'cp',...). Hm, Nick is also Slackware user... Good man. :-) (Maybe we should make a slackware package if we have bashburn 3.0 finished.) |
|
From: Nick W. <ni...@uk...> - 2008-10-07 16:50:58
|
On Mon, 06 Oct 2008 22:52:23 +0200
Markus Kollmar <mar...@on...> wrote:
> Yes you are right, I think also it is much work to grep the output of
> the burner-option (since it seems not strongly formated and some part
> of output goes not to stdout I think.)
As an aside on this, I too like Markus couldn't work out why some of
the dump goes to STDOUT and some doesn't seem to go anywhere yet still
gets printed to terminal.
i.e. compare:
cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive
with:
cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive > /dev/null
with:
cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive | grep -i
Driver
I dunno how Jörg Schilling has done this. In the man page quote:
"driveropts=option list
Set driver specific options. The options are specified a
comma separated list. To get a list of valid options use
driveropts=help together with the -checkdrive option. If you like to
set driver options without running a typical cdrecord task, you need to
use the -setdropts option in addition, otherwise the command line
parser in cdrecord will complain."
Command line parser? So he somehow does some magic?
I have never seen this behaviour in any application ever before.
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Anders L. <and...@gm...> - 2008-10-07 17:08:24
|
On Tuesday 07 October 2008 18:50:48 Nick Warne wrote: > On Mon, 06 Oct 2008 22:52:23 +0200 > > Markus Kollmar <mar...@on...> wrote: > > Yes you are right, I think also it is much work to grep the output of > > the burner-option (since it seems not strongly formated and some part > > of output goes not to stdout I think.) > > As an aside on this, I too like Markus couldn't work out why some of > the dump goes to STDOUT and some doesn't seem to go anywhere yet still > gets printed to terminal. > > i.e. compare: > > cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive > > with: > > cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive > /dev/null > > with: > > cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive | grep -i > Driver > > I dunno how Jörg Schilling has done this. In the man page quote: > > "driveropts=option list > Set driver specific options. The options are specified a > comma separated list. To get a list of valid options use > driveropts=help together with the -checkdrive option. If you like to > set driver options without running a typical cdrecord task, you need to > use the -setdropts option in addition, otherwise the command line > parser in cdrecord will complain." > > > Command line parser? So he somehow does some magic? > > I have never seen this behaviour in any application ever before. > > Nick Jörg is a strange man. I wouldn't be surprised if he uses black magic. -- Anders Lindén http://bashburn.dose.se |
|
From: Steven W. O. <st...@sy...> - 2008-10-08 02:48:38
|
On Tuesday, Oct 7th 2008 at 12:50 -0000, quoth Nick Warne: =>On Mon, 06 Oct 2008 22:52:23 +0200 =>Markus Kollmar <mar...@on...> wrote: => =>> Yes you are right, I think also it is much work to grep the output of =>> the burner-option (since it seems not strongly formated and some part =>> of output goes not to stdout I think.) => =>As an aside on this, I too like Markus couldn't work out why some of =>the dump goes to STDOUT and some doesn't seem to go anywhere yet still =>gets printed to terminal. => =>i.e. compare: => =>cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive => =>with: => =>cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive > /dev/null => =>with: => =>cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive | grep -i =>Driver => =>I dunno how J?rg Schilling has done this. In the man page quote: => =>"driveropts=option list => Set driver specific options. The options are specified a =>comma separated list. To get a list of valid options use =>driveropts=help together with the -checkdrive option. If you like to =>set driver options without running a typical cdrecord task, you need to =>use the -setdropts option in addition, otherwise the command line =>parser in cdrecord will complain." => => =>Command line parser? So he somehow does some magic? => =>I have never seen this behaviour in any application ever before. => =>Nick The reason is that that command writes to stderr and not to stdout. So, if you want your command to pipe its stderr to grep you have to say this: cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive 2>&1 | \ grep -i Driver which sez in English: "run the command and dup(2) stderr onto stdout and close stderr. Then take the combined stderr and stdout that is now on stdout and pipe it to grep." Make sense? -- 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-10-08 07:20:37
|
On Tue, 7 Oct 2008 22:48:22 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > > The reason is that that command writes to stderr and not to stdout. > So, if you want your command to pipe its stderr to grep you have to > say this: > > cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive 2>&1 | \ > grep -i Driver > > which sez in English: "run the command and dup(2) stderr onto stdout > and close stderr. Then take the combined stderr and stdout that is > now on stdout and pipe it to grep." > > Make sense? Yes, I think we all know about that... but it wasn't something I thought about. Anyway, it still is peculair. The line below NOW only prints out Driver Options (I guess 20 lines will be enough) but still have to dump to /dev/null. cdrecord dev=/dev/<you_drive> driveropts=help -checkdrive 2>&1 > /dev/null | grep -A 20 "Driver options" Please test this line - if it works for all of us, I guess it could be used to only print out drivers options. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Steven W. O. <st...@sy...> - 2008-10-08 14:56:48
|
On Wednesday, Oct 8th 2008 at 03:20 -0000, quoth Nick Warne: =>On Tue, 7 Oct 2008 22:48:22 -0400 (EDT) =>"Steven W. Orr" <st...@sy...> wrote: => =>> =>> The reason is that that command writes to stderr and not to stdout. =>> So, if you want your command to pipe its stderr to grep you have to =>> say this: =>> =>> cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive 2>&1 | \ =>> grep -i Driver =>> =>> which sez in English: "run the command and dup(2) stderr onto stdout =>> and close stderr. Then take the combined stderr and stdout that is =>> now on stdout and pipe it to grep." =>> =>> Make sense? => =>Yes, I think we all know about that... but it wasn't something I =>thought about. => =>Anyway, it still is peculair. The line below NOW only prints out Driver =>Options (I guess 20 lines will be enough) but still have to dump =>to /dev/null. => =>cdrecord dev=/dev/<you_drive> driveropts=help -checkdrive 2>&1 =>> /dev/null | grep -A 20 "Driver options" => =>Please test this line - if it works for all of us, I guess it could be =>used to only print out drivers options. That works. -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steven W. Orr |
|
From: Markus K. <mar...@on...> - 2008-10-08 09:37:21
|
Nick Warne wrote: > On Tue, 7 Oct 2008 22:48:22 -0400 (EDT) > "Steven W. Orr" <st...@sy...> wrote: > > >> The reason is that that command writes to stderr and not to stdout. >> So, if you want your command to pipe its stderr to grep you have to >> say this: >> >> cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive 2>&1 | \ >> grep -i Driver >> >> which sez in English: "run the command and dup(2) stderr onto stdout >> and close stderr. Then take the combined stderr and stdout that is >> now on stdout and pipe it to grep." >> >> Make sense? >> > > Yes, I think we all know about that... but it wasn't something I > thought about. > > Anyway, it still is peculair. The line below NOW only prints out Driver > Options (I guess 20 lines will be enough) but still have to dump > to /dev/null. > > cdrecord dev=/dev/<you_drive> driveropts=help -checkdrive 2>&1 > >> /dev/null | grep -A 20 "Driver options" >> > > Please test this line - if it works for all of us, I guess it could be > used to only print out drivers options. > > Nick > Nick, yes this works for me. Note, for those who first maybe wondered also about the "missing" redirection char: Some mail programms format the ">" before "/dev/null" to a graphical vertical line (they interpret it as reply-statements). Looking the message in source form shows that Nick formated it correct. :-) Markus |
|
From: Nick W. <ni...@uk...> - 2008-10-08 12:53:13
|
On Wed, 08 Oct 2008 11:37:17 +0200 Markus Kollmar <mar...@on...> wrote: > Note, for those who first maybe wondered also about the "missing" > redirection char: > Some mail programms format the ">" before "/dev/null" to a graphical > vertical line (they interpret it as reply-statements). Looking the > message in source form shows that Nick formated it correct. Yes, sometimes the 'quoted text' marks bugger up a 'proper' > when in the reply. I dunno how to get around it. I use claws-mail Nick -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@uk...> - 2008-10-08 11:25:50
|
On Wed, 08 Oct 2008 11:37:17 +0200 Markus Kollmar <mar...@on...> wrote: > Nick Warne wrote: > > On Tue, 7 Oct 2008 22:48:22 -0400 (EDT) > > "Steven W. Orr" <st...@sy...> wrote: > > > > > >> The reason is that that command writes to stderr and not to stdout. > >> So, if you want your command to pipe its stderr to grep you have to > >> say this: > >> > >> cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive 2>&1 | \ > >> grep -i Driver > >> > >> which sez in English: "run the command and dup(2) stderr onto > >> stdout and close stderr. Then take the combined stderr and stdout > >> that is now on stdout and pipe it to grep." > >> > >> Make sense? > >> > > > > Yes, I think we all know about that... but it wasn't something I > > thought about. > > > > Anyway, it still is peculair. The line below NOW only prints out > > Driver Options (I guess 20 lines will be enough) but still have to > > dump to /dev/null. > > > > cdrecord dev=/dev/<you_drive> driveropts=help -checkdrive 2>&1 > > > >> /dev/null | grep -A 20 "Driver options" > >> > > > > Please test this line - if it works for all of us, I guess it could > > be used to only print out drivers options. > > > > Nick > > > > Nick, yes this works for me. > > Note, for those who first maybe wondered also about the "missing" > redirection char: > Some mail programms format the ">" before "/dev/null" to a graphical > vertical line (they interpret it as reply-statements). Looking the > message in source form shows that Nick formated it correct. > > :-) > OK, I will commit this to TRUNK. Also I have appended an extra message to lang/German/Swedish/English/configure.lang to bb_conf_ch_dropts. This adds a 'Detecting CD Writer...' (using bb_text_7). The reason I done this is due to me having two drives. One dumps the options to the screen immediately, and the other takes about 3 seconds - so I end up looking at a blank screen wondering what is happening. This message now tells the user that the drive is being queried. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@uk...> - 2008-10-08 12:36:39
|
On Wed, 8 Oct 2008 12:25:36 +0100 Nick Warne <ni...@uk...> wrote: > On Wed, 08 Oct 2008 11:37:17 +0200 > Markus Kollmar <mar...@on...> wrote: > > > Nick Warne wrote: > > > On Tue, 7 Oct 2008 22:48:22 -0400 (EDT) > > > "Steven W. Orr" <st...@sy...> wrote: > > > > > > > > >> The reason is that that command writes to stderr and not to > > >> stdout. So, if you want your command to pipe its stderr to grep > > >> you have to say this: > > >> > > >> cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive 2>&1 > > >> | \ grep -i Driver > > >> > > >> which sez in English: "run the command and dup(2) stderr onto > > >> stdout and close stderr. Then take the combined stderr and stdout > > >> that is now on stdout and pipe it to grep." > > >> > > >> Make sense? > > >> > > > > > > Yes, I think we all know about that... but it wasn't something I > > > thought about. > > > > > > Anyway, it still is peculair. The line below NOW only prints out > > > Driver Options (I guess 20 lines will be enough) but still have to > > > dump to /dev/null. > > > > > > cdrecord dev=/dev/<you_drive> driveropts=help -checkdrive 2>&1 > > > > > >> /dev/null | grep -A 20 "Driver options" > > >> > > > > > > Please test this line - if it works for all of us, I guess it > > > could be used to only print out drivers options. > > > > > > Nick > > > > > > > Nick, yes this works for me. > > > > Note, for those who first maybe wondered also about the "missing" > > redirection char: > > Some mail programms format the ">" before "/dev/null" to a > > graphical vertical line (they interpret it as reply-statements). > > Looking the message in source form shows that Nick formated it > > correct. > > > > :-) > > > > OK, I will commit this to TRUNK. Also I have appended an extra > message to lang/German/Swedish/English/configure.lang to > bb_conf_ch_dropts. This adds a 'Detecting CD Writer...' (using > bb_text_7). > > The reason I done this is due to me having two drives. One dumps the > options to the screen immediately, and the other takes about 3 seconds > - so I end up looking at a blank screen wondering what is happening. > This message now tells the user that the drive is being queried. Now we need a way to report that the drive /dev/ entered is invalid if no option is produced. i.e. change to /dev/cdrom999 and then look at drive options... Perhaps this could be done in Option 0) setting CD writer menu - get cdrecord to -checkdrive and if no output or error etc. tell the user. EXAMPLE: #: cdrecord dev=/dev/cdrom99 driveropts=help -checkdrive Cdrecord-ProDVD-ProBD-Clone 2.01.01a38 (i686-pc-linux-gnu) Copyright (C) 1995-2008 Jörg Schilling scsidev: '/dev/cdrom99' devname: '/dev/cdrom99' scsibus: -2 target: -2 lun: -2 Warning: Open by 'devname' is unintentional and not supported. cdrecord: No such file or directory. Cannot open '/dev/cdrom99'. Cannot open or use SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. cdrecord: For possible transport specifiers try 'cdrecord dev=help'. Nick -- Free Software Foundation Associate Member 5508 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X