Thread: [Bashburn-info] 2nd try: I have a bash compatibility question (fwd)
Brought to you by:
bashburn
Menu
▾
▴
bashburn-info
|
From: Steven W. O. <st...@sy...> - 2008-09-20 10:45:40
|
---------- 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? -- 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: Anders L. <and...@gm...> - 2008-09-20 11:07:27
|
I say version 3 is so common now that we can focus on supporting just that version. Any newer distro has version 3 included so there shouldn't be any problems. Anyone disagree? On Sat, 2008-09-20 at 06:45 -0400, 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? > -- Anders Lindén http://bashburn.sf.net |
|
From: Nick W. <ni...@li...> - 2008-09-20 12:10:10
|
On Sat, 20 Sep 2008 13:06:37 +0200 Anders Lindén <and...@gm...> wrote: > I say version 3 is so common now that we can focus on supporting just > that version. Any newer distro has version 3 included so there > shouldn't be any problems. > > Anyone disagree? > > > On Sat, 2008-09-20 at 06:45 -0400, 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? > > Nope, I think 3.xx.xx has been out a while now (2005 ?). Nick -- Free Software Foundation Associate Member 5508 |
|
From: Markus K. <mar...@on...> - 2008-09-20 21:23:24
|
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:
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
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
o Brace expansion has been extended with a new {x..y} form, producing
sequences of digits or characters
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
o The `[[' command can now perform extended regular expression (egrep-like)
matching, with matched subexpressions placed in the BASH_REMATCH array
variable
o A new `pipefail' option causes a pipeline to return a failure status if
any command in it fails
o The `jobs', `kill', and `wait' builtins now accept job control notation
in their arguments even if job control is not enabled
o The `gettext' package and libintl have been integrated, and the shell
messages may be translated into other languages
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")?
Markus
|
|
From: Steven W. O. <st...@sy...> - 2008-09-21 00:42:31
|
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
|
|
From: Nick W. <ni...@li...> - 2008-09-21 10:46:15
|
On Sat, 20 Sep 2008 20:42:23 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:
> =>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 ;-)
I have messed about with UTF8 before, and it messes my shell up (e.g.
there is a bug in grep using the --color option).
But again, using English, I have never had any real reason to use UTF8.
Perhaps the languages that require it can use it - but you have to
remember (I think) the shell/system needs to be set to UTF8 anyway.
Nick
--
Free Software Foundation Associate Member 5508
|
Thanks for helping keep SourceForge clean.
X