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

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

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

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

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


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

I have not played with this yet.

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

Probably not relevant.

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

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

vs

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

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

Looks useful.

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

Not useful for bb.

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

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

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

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

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

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

Not so much.

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

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

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

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


-- 
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net