bashburn-info Mailing List for BashBurn (Page 9)
Brought to you by:
bashburn
Menu
▾
▴
bashburn-info — BashBurn mailing list
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(3) |
Mar
|
Apr
(31) |
May
(5) |
Jun
(10) |
Jul
(21) |
Aug
(9) |
Sep
(9) |
Oct
(5) |
Nov
|
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(4) |
Feb
(7) |
Mar
|
Apr
(6) |
May
(1) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
(7) |
Nov
(3) |
Dec
(17) |
| 2007 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
(8) |
Aug
(114) |
Sep
(283) |
Oct
(128) |
Nov
|
Dec
(1) |
|
From: Nick W. <ni...@li...> - 2008-09-25 21:01:13
|
On Thu, 25 Sep 2008 10:56:12 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > Nick, Maybe I'm not getting it. I sense that CTH.lang is used as a > stopgap to provide in case a language is not supported. But if we're > in Swahili and the language is not supported then we should default > to English instead of creating a copy of an English language file. At > the most, we should be looking to see in BBLANG is in the set of > supported languages and if it's not then set it to English. Yes? No? Yes and no. Look at the lang/Italian/configure.lang file (e.g.) It does not HAVE the $VARs associated with the help file, whether it is in Swahili, Klingon, or any other language. If the $VARs do not exist, then nothing gets sourced and no help text when it that language. The rest of the file[s] for menu etc. work OK... so it cannot just be reverted to English as default - just the 'not updated' variables in these files. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@li...> - 2008-09-25 20:53:21
|
On Thu, 25 Sep 2008 11:31:01 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > On Thursday, Sep 25th 2008 at 09:58 -0000, quoth Nick Warne: > > =>OK, I just discovered a dodgy bug. > => > =>Go to any menu, and hit escape key 3 or 4 times. You get a full > =>offered a full directory listing. > => > =>I guess we need to assign this key similar to SIGNAL type > assignment. => > =>Nick > > That's a feature. :-) > > I'm not exactly sure what it's hooked up to but it's a readline > thing, one of the Completing commands. This one completes based on > all possible commands. It's probably one of these: > > possible-command-completions (C-x !) > List the possible completions of the text before point, > treating it as a command name. > dynamic-complete-history (M-TAB) > Attempt completion on the text before point, comparing > the text against lines from the history list for possible > completion matches. > > If it's *really* a problem, we could create an inputrc for bb to have > an alternate initialization of readline. > > As it sits now, it has nothingh to do with bb. OK. Is/could it be a problem though? Is there no way to catch the escape key? I mean, who would press escape key 3 or 4 times other than a moron like me :-) Nick -- Free Software Foundation Associate Member 5508 |
|
From: Steven W. O. <st...@sy...> - 2008-09-25 15:31:08
|
On Thursday, Sep 25th 2008 at 09:58 -0000, quoth Nick Warne:
=>OK, I just discovered a dodgy bug.
=>
=>Go to any menu, and hit escape key 3 or 4 times. You get a full
=>offered a full directory listing.
=>
=>I guess we need to assign this key similar to SIGNAL type assignment.
=>
=>Nick
That's a feature. :-)
I'm not exactly sure what it's hooked up to but it's a readline thing, one
of the Completing commands. This one completes based on all possible
commands. It's probably one of these:
possible-command-completions (C-x !)
List the possible completions of the text before point, treating
it as a command name.
dynamic-complete-history (M-TAB)
Attempt completion on the text before point, comparing the text
against lines from the history list for possible completion
matches.
If it's *really* a problem, we could create an inputrc for bb to have an
alternate initialization of readline.
As it sits now, it has nothingh to do with bb.
--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net
|
|
From: Steven W. O. <st...@sy...> - 2008-09-25 15:17:00
|
On Thursday, Sep 25th 2008 at 06:27 -0000, quoth Nick Warne: =>Steve: Latest commit. I found a bug and located it to a funny => =>'eval $1' => =>in func/configfunc.sh. Commenting this out fixes the bug, and doesn't =>seem to break anything else... maybe you can have a butchers and see =>what you done here. Yes, I have no idea why that was there. I'll remove it. -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steve Orr Who should we vote for? http://steveo.syslang.net/electionrec-2008/ |
|
From: Steven W. O. <st...@sy...> - 2008-09-25 15:13:23
|
On Thursday, Sep 25th 2008 at 03:47 -0000, quoth Nick Warne:
=>I noticed the advanced menu help is out of kilter with the way the
=>normal configure help works.
=>
=>I have committed a small change. Is this the way to go here?
=>
=>lang/English/advanced.lang
=>
=>New $VAR:
=>
=>bb_adv_cdburncmd_help=\
=>"This is the command to use to burn a CD.
=>The current command is ${BBOPTIONCOLOR}${BB_CDBURNCMD}${BBCOLOROFF}"
=>
=>and in BashBurn.sh
=>
=>advancedmenu[0]='bb_adv_cdburncmd@BB_CDBURNCMD@bb_adv_cdburncmd_help'
=>
=>You have to test in English, advanced menu, option 0 ONLY for the
=>moment.
=>
=>If it is the way to do it, then all the LANG advanced.lang files will
=>need changing to.
That looks good to me.
--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net
|
|
From: Steven W. O. <st...@sy...> - 2008-09-25 14:56:22
|
On Thursday, Sep 25th 2008 at 02:01 -0000, quoth Nick Warne:
=>On Wed, 24 Sep 2008 20:42:33 -0400 (EDT)
=>> I traced that back to BashBurn.sh which is doing this:
=>>
=>> source_language_modules
=>> . ${BBROOTDIR}/misc/configure_temp_help.lang
=>>
=>> We call source_language_modules to set the variables to be in the
=>> proper language and *then* we source in configure_temp_help.lang
=>> which overwrites some of the variables we defined. I just commented
=>> it out because if the default is to provide text in English then I
=>> thought we were already doing that just before calling
=>> source_language_modules.
=>>
=>> if [[ ! -d ${BBROOTDIR}/lang/${BBLANG} ]]
=>> then
=>> blah...
=>> sleep 3s
=>> # Since the set language did not exist,
=>> # set it to English and save the option
=>> # so that in the future this message is not
=>> # shown again.
=>> BBLANG=English
=>> apply_options
=>> fi
=>>
=>> So I'm at a loss to understand what the purpose is of C_T_H.lang and
=>> since it contains duplicate variable defs, it absolutely should be
=>> deleted. No?
=>>
=>> =>Should I shut down BB, start it again and then enter the config
=>> menu, =>the menu itself is still in Swedish, but the descriptions are
=>> now in =>English. Very strange.
=>>
=>> Fixed by commenting out . ${BBROOTDIR}/misc/configure_temp_help.lang
=>
=>OK, this was my fault. The idea is that if the $LANG configure.lang
=>file has not yet been updated to have the new 'description' variables
=>(see lang/Italian/configure.lang for an example), then NO help text is
=>printed at all. So what should happen is these variables get set
=>instead from configure_temp_help.lang, so at least there is help,
=>albeit in English.
=>
=>This is now fixed again correctly. I should have sourced
=>configure_temp_help.lang FIRST, so that it doesn't clobbered $LANG
=>configure.lang files that have the correct $VAR
=>
=>My testing shows this now works as it should. Anders, please attempt
=>to replicate previous error.
=>
=>Remember, as the name implies, this is only a temporary hack until all
=>the configure.lang files are updated. I have commented so in the code.
Nick, Maybe I'm not getting it. I sense that CTH.lang is used as a stopgap
to provide in case a language is not supported. But if we're in Swahili
and the language is not supported then we should default to English
instead of creating a copy of an English language file. At the most, we
should be looking to see in BBLANG is in the set of supported languages
and if it's not then set it to English. Yes? No?
--
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...@li...> - 2008-09-25 13:59:01
|
OK, I just discovered a dodgy bug. Go to any menu, and hit escape key 3 or 4 times. You get a full offered a full directory listing. I guess we need to assign this key similar to SIGNAL type assignment. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@li...> - 2008-09-25 13:00:12
|
On Thu, 25 Sep 2008 14:50:59 +0200
Anders Lindén <and...@gm...> wrote:
> Nice work guys, I tried the latest revision and it works as it should
> now.
> I also committed a tiny correction for BashBurn.sh. Without it the
> help for the first option in the advanced menu wasn't shown.
I saw that change. Please see my post, I was experimenting with the
advanced menu.
==== copy ====
I have committed a small change. Is this the way to go here?
lang/English/advanced.lang
New $VAR:
bb_adv_cdburncmd_help=\
"This is the command to use to burn a CD.
The current command is ${BBOPTIONCOLOR}${BB_CDBURNCMD}${BBCOLOROFF}"
and in BashBurn.sh
advancedmenu[0]='bb_adv_cdburncmd@BB_CDBURNCMD@bb_adv_cdburncmd_help'
You have to test in English, advanced menu, option 0 ONLY for the
moment.
If it is the way to do it, then all the LANG advanced.lang files will
need changing to.
===========
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Anders L. <and...@gm...> - 2008-09-25 12:51:12
|
Nice work guys, I tried the latest revision and it works as it should now. I also committed a tiny correction for BashBurn.sh. Without it the help for the first option in the advanced menu wasn't shown. -- Anders Lindén http://bashburn.sf.net |
|
From: Nick W. <ni...@li...> - 2008-09-25 10:27:38
|
Steve: Latest commit. I found a bug and located it to a funny 'eval $1' in func/configfunc.sh. Commenting this out fixes the bug, and doesn't seem to break anything else... maybe you can have a butchers and see what you done here. Markus: I have added a new test $VAR in lang/English/advanced.sh; bb_adv_cdburncmd_help please review and see what we need/can do here with the LANG files if this is the way to go. All the other advanced commands will need similar _help $VARS too, if that is the case. Also I have re-worded bb_conf_xit_2 in configure.lang, as the function has changed slightly and the original wording did not suit the new way it works. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@li...> - 2008-09-25 07:47:20
|
I noticed the advanced menu help is out of kilter with the way the
normal configure help works.
I have committed a small change. Is this the way to go here?
lang/English/advanced.lang
New $VAR:
bb_adv_cdburncmd_help=\
"This is the command to use to burn a CD.
The current command is ${BBOPTIONCOLOR}${BB_CDBURNCMD}${BBCOLOROFF}"
and in BashBurn.sh
advancedmenu[0]='bb_adv_cdburncmd@BB_CDBURNCMD@bb_adv_cdburncmd_help'
You have to test in English, advanced menu, option 0 ONLY for the
moment.
If it is the way to do it, then all the LANG advanced.lang files will
need changing to.
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Nick W. <ni...@li...> - 2008-09-25 07:08:31
|
On Wed, 24 Sep 2008 23:17:51 +0200 Anders Lindén <and...@gm...> wrote: > Finally, in the advanced menu, no option descriptions are ever > printed. > OK, I have fixed that - this should now work properly. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@li...> - 2008-09-25 06:01:18
|
On Wed, 24 Sep 2008 20:42:33 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:
> On Wednesday, Sep 24th 2008 at 17:17 -0000, quoth Anders Lind?n:
>
> =>I noticed some weird behaviour in the config menu.
> =>
> =>I switched from English to Swedish and applied my changes without
> =>exiting the config menu. When choosing an option in the config
> menu, the =>description is now in Swedish as it should be. I can exit
> the config =>menu, go back to it and the descriptions are in Swedish
> still.
>
> Should I shut down BB, start it again and then enter the config menu,
> the menu itself is still in Swedish, but the descriptions are now in
> English. Very strange.
>
>
> I traced that back to BashBurn.sh which is doing this:
>
> source_language_modules
> . ${BBROOTDIR}/misc/configure_temp_help.lang
>
> We call source_language_modules to set the variables to be in the
> proper language and *then* we source in configure_temp_help.lang
> which overwrites some of the variables we defined. I just commented
> it out because if the default is to provide text in English then I
> thought we were already doing that just before calling
> source_language_modules.
>
> if [[ ! -d ${BBROOTDIR}/lang/${BBLANG} ]]
> then
> blah...
> sleep 3s
> # Since the set language did not exist,
> # set it to English and save the option
> # so that in the future this message is not
> # shown again.
> BBLANG=English
> apply_options
> fi
>
> So I'm at a loss to understand what the purpose is of C_T_H.lang and
> since it contains duplicate variable defs, it absolutely should be
> deleted. No?
>
> =>Should I shut down BB, start it again and then enter the config
> menu, =>the menu itself is still in Swedish, but the descriptions are
> now in =>English. Very strange.
>
> Fixed by commenting out . ${BBROOTDIR}/misc/configure_temp_help.lang
OK, this was my fault. The idea is that if the $LANG configure.lang
file has not yet been updated to have the new 'description' variables
(see lang/Italian/configure.lang for an example), then NO help text is
printed at all. So what should happen is these variables get set
instead from configure_temp_help.lang, so at least there is help,
albeit in English.
This is now fixed again correctly. I should have sourced
configure_temp_help.lang FIRST, so that it doesn't clobbered $LANG
configure.lang files that have the correct $VAR
My testing shows this now works as it should. Anders, please attempt
to replicate previous error.
Remember, as the name implies, this is only a temporary hack until all
the configure.lang files are updated. I have commented so in the code.
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Steven W. O. <st...@sy...> - 2008-09-25 02:08:04
|
On Wednesday, Sep 24th 2008 at 17:17 -0000, quoth Anders Lind?n: =>I also notice that when the Swedish descriptions do show up, they use =>colors as they should. For instance when choosing whether to use =>normalize or not, yes is colored in green and no in red. In the english =>descriptions colors are never used. Ok. Fixed in 581. The problem was that the lang files were being sucked in *before* the colordefs happened. Therefore the color defs were null at the time that the info messages were defined. It should be better now. What I did *not* see was that it was working for Swedish and not for English. What is more likely is that it worked for neither, but that after you changed language in the same session, then the messages were recreated while the color defs had already been set. And the moral of the story is that what would have prevented this is for package definition to have occurred. Bash doesn't provide for it, but it would have been nice to for, for example, inside lang/English/configure.lang to say require color and inside misc/colors.idx to say provides color Alas :-( -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net |
|
From: Steven W. O. <st...@sy...> - 2008-09-25 00:42:47
|
Ok. First of all, the variable bb_menu_adv was not defined for all
languages. This means that Option 6 of the main menu would come up blank
unless it was English or Swedish. I fixed that by using bb_conf_menu_adv
instead.
On Wednesday, Sep 24th 2008 at 17:17 -0000, quoth Anders Lind?n:
=>I noticed some weird behaviour in the config menu.
=>
=>I switched from English to Swedish and applied my changes without
=>exiting the config menu. When choosing an option in the config menu, the
=>description is now in Swedish as it should be. I can exit the config
=>menu, go back to it and the descriptions are in Swedish still.
I traced that back to BashBurn.sh which is doing this:
source_language_modules
. ${BBROOTDIR}/misc/configure_temp_help.lang
We call source_language_modules to set the variables to be in the proper
language and *then* we source in configure_temp_help.lang which overwrites
some of the variables we defined. I just commented it out because if the
default is to provide text in English then I thought we were already doing
that just before calling source_language_modules.
if [[ ! -d ${BBROOTDIR}/lang/${BBLANG} ]]
then
blah...
sleep 3s
# Since the set language did not exist,
# set it to English and save the option
# so that in the future this message is not
# shown again.
BBLANG=English
apply_options
fi
So I'm at a loss to understand what the purpose is of C_T_H.lang and since
it contains duplicate variable defs, it absolutely should be deleted. No?
=>Should I shut down BB, start it again and then enter the config menu,
=>the menu itself is still in Swedish, but the descriptions are now in
=>English. Very strange.
Fixed by commenting out . ${BBROOTDIR}/misc/configure_temp_help.lang
=>I also notice that when the Swedish descriptions do show up, they use
=>colors as they should. For instance when choosing whether to use
=>normalize or not, yes is colored in green and no in red. In the english
=>descriptions colors are never used.
I'll look at that.
=>
=>Finally, in the advanced menu, no option descriptions are ever printed.
AFAIK, the option descriptions never existed. Do you know were they might
have existed in svn history?
--
steveo at syslang dot net TMMP1 http://frambors.syslang.net/
Do you have neighbors who are not frambors? Steve Orr
Who should we vote for? http://steveo.syslang.net/electionrec-2008/
|
|
From: Anders L. <and...@gm...> - 2008-09-24 21:18:08
|
I noticed some weird behaviour in the config menu. I switched from English to Swedish and applied my changes without exiting the config menu. When choosing an option in the config menu, the description is now in Swedish as it should be. I can exit the config menu, go back to it and the descriptions are in Swedish still. Should I shut down BB, start it again and then enter the config menu, the menu itself is still in Swedish, but the descriptions are now in English. Very strange. I also notice that when the Swedish descriptions do show up, they use colors as they should. For instance when choosing whether to use normalize or not, yes is colored in green and no in red. In the english descriptions colors are never used. Finally, in the advanced menu, no option descriptions are ever printed. -- Anders Lindén http://bashburn.sf.net |
|
From: Steven W. O. <st...@sy...> - 2008-09-24 14:06:54
|
On Wednesday, Sep 24th 2008 at 08:10 -0000, quoth Nick Warne:
=>OK, this may surprise you guys.
=>
=>Apart from actually burning anything, the only issue I can see now is I
=>still cannot enter data in the configure menu 'author' field properly.
=>'@' still doesn't work right, and it takes a few efforts to get a space
=>in between words from scratch,
=>
=>I think once that is done, we can move this over.
=>
=>Then I reckon we need to test functionality before anything else gets
=>changed.
=>
=>Agree?
=>
=>Nick
It amazes mehow software can still be broken after it gets looked at. I'm
starting to feel more humble by the minute. :-(
Fixed in 578.
- eval "$CFG_CHANGES[ii]=${var}\|\"${input}\""
+ eval "$CFG_CHANGES[ii]=\"${var}|${input}\""
- (( found )) || eval "$CFG_CHANGES[chsize]"="${var}\|${input}"
+ (( found )) || eval "$CFG_CHANGES[chsize]=\"${var}|${input}\""
Don't look too closely or your brain will explode. I know mine did.
--
steveo at syslang dot net TMMP1 http://frambors.syslang.net/
Do you have neighbors who are not frambors? Steve Orr
Who should we vote for? http://steveo.syslang.net/electionrec-2008/
|
|
From: Anders L. <and...@gm...> - 2008-09-24 13:04:31
|
ons 2008-09-24 klockan 13:10 +0100 skrev Nick Warne: > OK, this may surprise you guys. > > Apart from actually burning anything, the only issue I can see now is I > still cannot enter data in the configure menu 'author' field properly. > '@' still doesn't work right, and it takes a few efforts to get a space > in between words from scratch, > > I think once that is done, we can move this over. > > Then I reckon we need to test functionality before anything else gets > changed. > > Agree? > > Nick Agree. I think we should now focus on getting things working properly, not add any new features or do any "unnecessary" rewrites. Once things work and translations are updated (English, Swedish and German at least) we should release 3.0. I'm sure there are things that can be improved but I think we should wait with those changes for 3.1 or so. -- Anders Lindén http://bashburn.sf.net |
|
From: Nick W. <ni...@li...> - 2008-09-24 12:10:22
|
OK, this may surprise you guys. Apart from actually burning anything, the only issue I can see now is I still cannot enter data in the configure menu 'author' field properly. '@' still doesn't work right, and it takes a few efforts to get a space in between words from scratch, I think once that is done, we can move this over. Then I reckon we need to test functionality before anything else gets changed. Agree? Nick -- Free Software Foundation Associate Member 5508 |
|
From: Nick W. <ni...@li...> - 2008-09-24 12:03:00
|
On Wed, 24 Sep 2008 13:34:16 +0200 Anders Lindén <and...@gm...> wrote: > Nick, that is an awesome logo. :-) > BashBurn is now an 11 on the awesome scale. > > Also, I created a docs directory and moved the documentation files > into it. > Heh. Good stuff. I just also tidied up the Installation reports a bit too. Looks very nice now when installing it. This is getting very good. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Anders L. <and...@gm...> - 2008-09-24 11:58:24
|
Nick, that is an awesome logo. :-) BashBurn is now an 11 on the awesome scale. Also, I created a docs directory and moved the documentation files into it. -- Anders Lindén http://bashburn.sf.net |
|
From: Steven W. O. <st...@sy...> - 2008-09-23 15:01:59
|
On Tuesday, Sep 23rd 2008 at 09:50 -0000, quoth Nick Warne:
=>On Tue, 23 Sep 2008 09:46:33 -0400 (EDT)
=>"Steven W. Orr" <st...@sy...> wrote:
=>
=>> On Tuesday, Sep 23rd 2008 at 09:34 -0000, quoth Nick Warne:
=>>
=>> =>OK, good stuff, but issue #1 still fails:
=>> =>
=>> =>--> The grep function that pulls in the (regex'ed) fstab entries
=>> =>--> doesn't work when you go to configure devices - I don't know
=>> why. =>
=>> =>There should be a list like /dev/cdrom /mnt/cdrom etc. appear at the
=>> =>bottom when entering configuration options 0) 1) and 2)
=>>
=>> Also fixed. Thanks :-)
=>>
=>> 565 > svn ci
=>> Sending trunk/BashBurn.sh
=>> Sending trunk/menus/bbmenu.sh
=>> Transmitting file data ..
=>> Committed revision 566.
=>
=>info_cmd[ii]="${!4}"
=>
=>I don't think I would have got that in a million years (well,
=>maybe ;-) )
=>
=>Good stuff.
It's an important idiom. It's one of the ways that bash can simulate
something that vaguely smells like pointers.
foo=abc
bar=foo
echo "${!bar} == abc"
Before this construct was supported, we had to do it the hard way.
foo=abc
bar=foo
echo $(eval "echo \$${bar}")
One of the problems with bash is that it doesn't give us the ability to
indirect through the name of an array variable.
That leads to uglyosities like this in bbconfmenu. menuname is something
like conf_menuitems or advancedmenu.
size=$(eval "echo \"\${#$menuname[@]}\"" )
for (( ii=0; ii<size; ii++ ))
do
descriptors[ii]=$(eval "echo \"\${$menuname[ii]}\"" )
done
--
steveo at syslang dot net TMMP1 http://frambors.syslang.net/
Do you have neighbors who are not frambors? Steve Orr
Who should we vote for? http://steveo.syslang.net/electionrec-2008/
|
|
From: Nick W. <ni...@li...> - 2008-09-23 13:51:04
|
On Tue, 23 Sep 2008 09:46:33 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:
> On Tuesday, Sep 23rd 2008 at 09:34 -0000, quoth Nick Warne:
>
> =>OK, good stuff, but issue #1 still fails:
> =>
> =>--> The grep function that pulls in the (regex'ed) fstab entries
> =>--> doesn't work when you go to configure devices - I don't know
> why. =>
> =>There should be a list like /dev/cdrom /mnt/cdrom etc. appear at the
> =>bottom when entering configuration options 0) 1) and 2)
>
> Also fixed. Thanks :-)
>
> 565 > svn ci
> Sending trunk/BashBurn.sh
> Sending trunk/menus/bbmenu.sh
> Transmitting file data ..
> Committed revision 566.
info_cmd[ii]="${!4}"
I don't think I would have got that in a million years (well,
maybe ;-) )
Good stuff.
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Steven W. O. <st...@sy...> - 2008-09-23 13:46:40
|
On Tuesday, Sep 23rd 2008 at 09:34 -0000, quoth Nick Warne: =>OK, good stuff, but issue #1 still fails: => =>--> The grep function that pulls in the (regex'ed) fstab entries =>--> doesn't work when you go to configure devices - I don't know why. => =>There should be a list like /dev/cdrom /mnt/cdrom etc. appear at the =>bottom when entering configuration options 0) 1) and 2) Also fixed. Thanks :-) 565 > svn ci Sending trunk/BashBurn.sh Sending trunk/menus/bbmenu.sh Transmitting file data .. Committed revision 566. -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steve Orr Who should we vote for? http://steveo.syslang.net/electionrec-2008/ |
|
From: Steven W. O. <st...@sy...> - 2008-09-23 13:37:09
|
On Tuesday, Sep 23rd 2008 at 08:05 -0000, quoth Nick Warne: =>On Tue, 23 Sep 2008 13:46:05 +0200 =>Markus Kollmar <mar...@on...> wrote: => =>> I have added a new file "TRANSLATION_RULE" in the base language =>> directory of trunk. =>> =>> It should describe the process of translation. So we can work =>> upon/with this "specification". =>> But until now it is more a discussion-point - if someone has =>> improvements or additional ideas, it's welcome. =>> =>> (Note, that I am not online until friday or saturday. So I can't =>> response in this time, but when I am back I do so.) => =>Good idea, but we need to do something here. => =>As the file will need to be added to the install script, this then =>introduces an additional problem, as the way BB selects lang list in =>the configuration is to actually 'ls -1' the lang/ directory - this =>means TRANSLATION_RULE will show up as a language! => =>So, either change the way the lang/directories are shown (somehow only =>list directories), OR, which I prefer, is to create a doc/ directory =>whereby all the related information files can live. One thing I should mention. In order to implement the pre-loading of the history buffer for use of the read command when trying to read a possibly enumerated value, I changed the ls command of the lang directory from ls -C to ls -1. I did this because in the case of BBLANG, we each word that came out of the command needed to be loaded into the history buffer. But in the case of the grep command to see what the possible devices are, we were really only concerned with the first word of each line of output. Currently I'm loading the whole line into the history buffer, but I really need to change it so that only the first word of each line gets loaded. I can always change it to do anything we want, but I just wanted to exaplin why we used to be doing an ls -C and now it's ls -1. -- steveo at syslang dot net TMMP1 http://frambors.syslang.net/ Do you have neighbors who are not frambors? Steve Orr Who should we vote for? http://steveo.syslang.net/electionrec-2008/ |
8 messages has been excluded from this view by a project administrator.
