Re: bash 3.2.39 -- race condition

[Marc Herbert]

Douglas Moyes a écrit :
> I nearly brought down a server today.
> 
> # alias d="perl-script "
> 

A long time ago I read somewhere that aliases are not recommended. I
think they do not bring anything on the table compared to functions, do
they?

Anyway I have always done without them, but without understanding what I
gained. Now I know a bit better, thanks!

Re: IFS handling and read

[Marc Herbert]

Eric Blake a écrit :
> 
> This is E4 in the FAQ:
> ftp://ftp.cwru.edu/pub/bash/FAQ
> 
> POSIX permits, but does not require, that the final element of a pipeline
> be executed in a subshell.  Bash uses the subshell, ksh does not.
> Variable assignments in a subshell do not affect the parent.

I am regularly bitten by this. This is a major pain; it makes "read" very
inconvenient to use (whatever IFS is).

Could this be changed in the future?

Cheers,

Marc

Re: IFS handling and read

[Lhunath (Maarten B.)]

On 30 Nov 2009, at 11:34, Marc Herbert wrote:

> Eric Blake a écrit :
>> 
>> This is E4 in the FAQ:
>> ftp://ftp.cwru.edu/pub/bash/FAQ
>> 
>> POSIX permits, but does not require, that the final element of a pipeline
>> be executed in a subshell.  Bash uses the subshell, ksh does not.
>> Variable assignments in a subshell do not affect the parent.
> 
> I am regularly bitten by this. This is a major pain; it makes "read" very
> inconvenient to use (whatever IFS is).
> 
> Could this be changed in the future?

Don't use pipelines to send streams to read.  Use file redirection instead:

Instead of ''command | read var''
Use ''read var < <(command)''

I hardly see a need to change the existing implementation.

operators available in bash versions

[Gerard]

I apologize for asking what is probably a dumb question, but where can
I find a definitive listing of what features are available in each
version of Bash.

For example, I only have access to Bash-4 on my system. I need to know
if " $(< " also works on Bash < 4. I also have a few questions
regarding array handling.

I am running FreeBSD-7.2 and installed Bash via ports.

-- 
Gerard
ger...@seibercom.net

|===
|===
|===
|===
|

Too much is not enough.

Re: operators available in bash versions

[Lhunath (Maarten B.)]

On 30 Nov 2009, at 12:12, Gerard wrote:

> 
> I apologize for asking what is probably a dumb question, but where can
> I find a definitive listing of what features are available in each
> version of Bash.
> 
> For example, I only have access to Bash-4 on my system. I need to know
> if " $(< " also works on Bash < 4. I also have a few questions
> regarding array handling.
> 
> I am running FreeBSD-7.2 and installed Bash via ports.
> 

The following is not a bad reference:

http://mywiki.wooledge.org/BashFAQ/061

Re: bash 3.2.39 -- race condition

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Marc Herbert on 11/30/2009 3:18 AM:
> A long time ago I read somewhere that aliases are not recommended. I
> think they do not bring anything on the table compared to functions, do
> they?

There is one thing that aliases can do that functions cannot - and that is
control how the rest of the statement is parsed.  This can be exploited to
write an alias for find that calls a function with globbing temporarily
turned off for the rest of the statement; the function then restores
globbing state after executing the real find under the hood.

http://www.chiark.greenend.org.uk/~sgtatham/aliases.html

But yes, other than cool hacks like that, functions are almost always
hands down more powerful than aliases.

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksTwWUACgkQ84KuGfSFAYAhdwCcCO7fGXLSu9QYODSr/lsK765Y
kOcAoMnj6ZKikCBKRDlC6dCluycSWaQ2
=kfKZ
-END PGP SIGNATURE-

Re: IFS handling and read

[Greg Wooledge]

On Mon, Nov 30, 2009 at 11:46:03AM +0100, Lhunath (Maarten B.) wrote:
> Don't use pipelines to send streams to read.  Use file redirection instead:
> 
> Instead of ''command | read var''
> Use ''read var < <(command)''
> 
> I hardly see a need to change the existing implementation.

Or for the original problem case, use a here string:

IFS=: read a b <<< "1:2"

Between process substitutions (the <(command) thing) and here strings,
you should be able to do all your reads without subshells.

Re: IFS handling and read

[Marc Herbert]

Lhunath (Maarten B.) a écrit :
> On 30 Nov 2009, at 11:34, Marc Herbert wrote:
> 
>> Eric Blake a écrit :
>>> This is E4 in the FAQ:
>>> ftp://ftp.cwru.edu/pub/bash/FAQ

> Instead of ''commands | read var''
> Use ''read var < <(commands)''
> I hardly see a need to change the existing implementation.

As mentioned in the FAQ, ''read var < <(commands)'' is not portable.

All alternatives in the FAQ (portable or not) are less readable than a
simple pipe. They are all more verbose and introduce an extra level of
nesting when you have only one "command". They all need to be read
"backwards" with respect to the execution flow. If you want to keep your
code readable, they practically all force you to define a function for
"commands" as soon as you have more than a few commands.

Every entry in an FAQ is by mere definition a problem that many people
wast... spend time on.

It is admittedly not a question of life or death but some other shells
apparently have it so why not bash? Just asking.

Re: IFS handling and read

[Lhunath (Maarten B.)]

On 30 Nov 2009, at 14:10, Marc Herbert wrote:
> 
> Lhunath (Maarten B.) a écrit :
>> On 30 Nov 2009, at 11:34, Marc Herbert wrote:
>> 
>>> Eric Blake a écrit :
 This is E4 in the FAQ:
 ftp://ftp.cwru.edu/pub/bash/FAQ
> 
>> Instead of ''commands | read var''
>> Use ''read var < <(commands)''
>> I hardly see a need to change the existing implementation.
> 
> As mentioned in the FAQ, ''read var < <(commands)'' is not portable.
> 
> All alternatives in the FAQ (portable or not) are less readable than a
> simple pipe. They are all more verbose and introduce an extra level of
> nesting when you have only one "command". They all need to be read
> "backwards" with respect to the execution flow. If you want to keep your
> code readable, they practically all force you to define a function for
> "commands" as soon as you have more than a few commands.
> 
> Every entry in an FAQ is by mere definition a problem that many people
> wast... spend time on.
> 
> It is admittedly not a question of life or death but some other shells
> apparently have it so why not bash? Just asking.

Let me try to guess what your definition of portability is by assuming it means 
"will run in any POSIX shell".

Firstly, if you are writing FOR the bash shell, you needn't worry about this 
type of portability.  Putting bash in your hashbang means the script will only 
ever be interpreted by a bash shell, not any other POSIX shell.

Secondly, if you do decide that for some reason you want to have your script 
interpretable by other POSIX shells (which means you avoid all other 
bash-specific features, too) your concern over portability still does not 
warrant the implementation being changed, as POSIX does not require shells to 
avoid subshelling components of a pipeline.  So you still can't rely on other 
non-bash shells that are POSIX-compliant to treat your script's implementation 
the same.

That said, the command substitution is an excellent alternative in any case for 
the pipeline-to-read problem.  It is clean and has no side-effects.  If your 
real issue is that many people struggle with this because they are newbies and 
haven't learned the intricacies of the shell yet, then surely this is not the 
first or biggest obstacle in that respect.  Even (self-)proclaimed bash 
geniuses still fail at quoting expansions properly because they do not 
understand or appreciate the intricacies of word-splitting and pathname 
expansions.

Re: <( error

[Greg Wooledge]

On Sat, Nov 28, 2009 at 02:57:45PM +0100, Antonio Macchi wrote:
> but, if you don't have hd (hexdump) how can you see the content of a, 
> for example, strange file
> 
> i mean
> 
> $ ls -l
> total 0
> -rw-r--r-- 1 user1 user1 0 2009-11-28 14:56 ?
> 
> $ hd <(ls)
>   09 0a |..|
> 0002

You aren't actually looking at the content of a "strange file".
You're trying to see its name.  For this specific case, you may want
"ls -b" instead.

>From HP-UX:

imadev:~$ touch $'\x09'; ls -lb ?
...
-rw-r--r--   1 wooledgpgmr 0 Nov 30 08:39 \011

Or from Linux:

arc3:~$ ls -lb ?
-rw-r--r-- 1 wooledg voice 0 2009-11-30 08:39 \t
...

(Don't bother asking why the GID mapping is different... it's a local
site legacy thing.)

Re: <( error

[Greg Wooledge]

On Sat, Nov 28, 2009 at 02:18:37PM +0100, Antonio Macchi wrote:
> $ hd <(echo -en \\0{0..3}{0..7}{0..7})

As for this, I wonder if you understand how bash handles this.
I know it certainly wasn't obvious to me!  Due to the way the parsing
is done, the brace expansions inside the proces substitution cause
the process substitution to be duplicated.  At least in bash 3.2.
Thus,

imadev:~$ bash-3.2.48 -c 'ls -l <(echo {a,b})'
prw---   1 wooledgpgmr 0 Nov 30 08:45 
/var/tmp//sh-np-1259598998
prw---   1 wooledgpgmr 0 Nov 30 08:45 
/var/tmp//sh-np-3711191228

The "ls -l <(echo {a,b})" is expanded exactly as if I had typed
"ls -l <(echo a) <(echo b)" instead.

However, this appears to have changed in bash 4.0:

imadev:~$ bash-4.0.35 -c 'ls -l <(echo {a,b})'
prw---   1 wooledgpgmr 0 Nov 30 08:47 
/var/tmp//sh-np-1259581617

(I wasn't previously aware of that change.)

Based on your question, I'm guessing you're in bash 3.2 or earlier, where
your "hd <(echo -en \\0{0..3}{0..7}{0..7})" is expanded as if you had typed
"hd <(echo -en \\) <(echo -en \\0001) <(echo -en \\0002) ..." and
runs into the FD exhaustion issue Chet already described.

I think you intended to get the bash-4.0 behavior, and not the bash-3.2
behavior.

Re: IFS handling and read

[Chris F.A. Johnson]

On Mon, 30 Nov 2009, Marc Herbert wrote:

> Lhunath (Maarten B.) a ?crit :
> > On 30 Nov 2009, at 11:34, Marc Herbert wrote:
> > 
> >> Eric Blake a ?crit :
> >>> This is E4 in the FAQ:
> >>> ftp://ftp.cwru.edu/pub/bash/FAQ
> 
> > Instead of ''commands | read var''
> > Use ''read var < <(commands)''
> > I hardly see a need to change the existing implementation.
> 
> As mentioned in the FAQ, ''read var < <(commands)'' is not portable.
> 
> All alternatives in the FAQ (portable or not) are less readable than a
> simple pipe. They are all more verbose and introduce an extra level of
> nesting when you have only one "command". They all need to be read
> "backwards" with respect to the execution flow. If you want to keep your
> code readable, they practically all force you to define a function for
> "commands" as soon as you have more than a few commands.
> 
> Every entry in an FAQ is by mere definition a problem that many people
> wast... spend time on.
> 
> It is admittedly not a question of life or death but some other shells
> apparently have it so why not bash? Just asking.

   Why should it be the last element of a pipeline that is executed in
   the current shell and not the first?

   Suppose that I have a group of commands that sets some variables
   and outputs information to the screen, for example (this is much
   oversimplified):

{
  x=$(( $something * 2 ))
  printf "%d\n" "$x"
}

   Now, I want to modify the output. I pipe it through a formatting
   command:

{
  x=$(( $something * 2 ))
  printf "%d\n" "$x"
} | tr 0-9 9-0

   All of a sudden, x is not set (or set to the wrong value). So it
   should be the *first* command, not the last, that is executed in
   the calling shell.

-- 
   Chris F.A. Johnson, webmaster 
   ===
   Author:
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
   Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)

Re: IFS handling and read

[Chris F.A. Johnson]

On Mon, 30 Nov 2009, Greg Wooledge wrote:

> On Mon, Nov 30, 2009 at 11:46:03AM +0100, Lhunath (Maarten B.) wrote:
> > Don't use pipelines to send streams to read.  Use file redirection instead:
> > 
> > Instead of ''command | read var''
> > Use ''read var < <(command)''
> > 
> > I hardly see a need to change the existing implementation.
> 
> Or for the original problem case, use a here string:
> 
> IFS=: read a b <<< "1:2"
> 
> Between process substitutions (the <(command) thing) and here strings,
> you should be able to do all your reads without subshells.

   Or, to be portable, use a here document:

IFS=: read a b <<.
1:2
.

   This works with the output of commands, too:

IFS=- read year month day <<.
$(date +%Y-%m-%d)
.

-- 
   Chris F.A. Johnson, webmaster 
   ===
   Author:
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
   Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)

Re: IFS handling and read

[Lhunath (Maarten B.)]

On 30 Nov 2009, at 15:56, Chris F.A. Johnson wrote:
> 
> On Mon, 30 Nov 2009, Greg Wooledge wrote:
> 
>> On Mon, Nov 30, 2009 at 11:46:03AM +0100, Lhunath (Maarten B.) wrote:
>>> Don't use pipelines to send streams to read.  Use file redirection instead:
>>> 
>>> Instead of ''command | read var''
>>> Use ''read var < <(command)''
>>> 
>>> I hardly see a need to change the existing implementation.
>> 
>> Or for the original problem case, use a here string:
>> 
>> IFS=: read a b <<< "1:2"
>> 
>> Between process substitutions (the <(command) thing) and here strings,
>> you should be able to do all your reads without subshells.
> 
>   Or, to be portable, use a here document:
> 
> IFS=: read a b <<.
> 1:2
> .
> 
>   This works with the output of commands, too:
> 
> IFS=- read year month day <<.
> $(date +%Y-%m-%d)
> .

Note that 'read' is a bash feature; not a POSIX shell feature.  In that sense, 
"read" alone is limiting your "portability".  So portability in the meaning of 
POSIX is out of the question.

Perhaps you're talking about backward compatibility instead of portability, in 
which case the only compatibility gain you get from using the more verbose 
heredoc over the herestring is compatibiltiy with pre-2.05b-alpha1 bash.

Hardly worth it.

Re: IFS handling and read

[Chris F.A. Johnson]

On Mon, 30 Nov 2009, Lhunath (Maarten B.) wrote:

> On 30 Nov 2009, at 15:56, Chris F.A. Johnson wrote:
> > 
> > On Mon, 30 Nov 2009, Greg Wooledge wrote:
> > 
> >> On Mon, Nov 30, 2009 at 11:46:03AM +0100, Lhunath (Maarten B.) wrote:
> >>> Don't use pipelines to send streams to read.  Use file redirection 
> >>> instead:
> >>> 
> >>> Instead of ''command | read var''
> >>> Use ''read var < <(command)''
> >>> 
> >>> I hardly see a need to change the existing implementation.
> >> 
> >> Or for the original problem case, use a here string:
> >> 
> >> IFS=: read a b <<< "1:2"
> >> 
> >> Between process substitutions (the <(command) thing) and here strings,
> >> you should be able to do all your reads without subshells.
> > 
> >   Or, to be portable, use a here document:
> > 
> > IFS=: read a b <<.
> > 1:2
> > .
> > 
> >   This works with the output of commands, too:
> > 
> > IFS=- read year month day <<.
> > $(date +%Y-%m-%d)
> > .
> 
> Note that 'read' is a bash feature; not a POSIX shell feature.

?

The read command has been around since the early Bourne shells.

>  In that sense, "read" alone is limiting your "portability". So
> portability in the meaning of POSIX is out of the question.

> Perhaps you're talking about backward compatibility instead of
> portability, in which case the only compatibility gain you get from
> using the more verbose heredoc over the herestring is compatibiltiy
> with pre-2.05b-alpha1 bash.

> Hardly worth it.
> 

-- 
   Chris F.A. Johnson, webmaster 
   ===
   Author:
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
   Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)

Re: IFS handling and read

[Andreas Schwab]

"Chris F.A. Johnson"  writes:

>This works with the output of commands, too:
>
> IFS=- read year month day <<.
> $(date +%Y-%m-%d)
> .

The disadvantage is that the command is executed synchronously.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: IFS handling and read

[Chet Ramey]

Lhunath (Maarten B.) wrote:

> Note that 'read' is a bash feature; not a POSIX shell feature.  In that 
> sense, "read" alone is limiting your "portability".  So portability in the 
> meaning of POSIX is out of the question.

Pardon me?  `read' is a feature of every historical shell and standardized
by Posix.  The bash implementation is a superset of Posix.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: IFS handling and read

[Lhunath (Maarten B.)]

On 30 Nov 2009, at 16:15, Chet Ramey wrote:
> 
> Lhunath (Maarten B.) wrote:
> 
>> Note that 'read' is a bash feature; not a POSIX shell feature.  In that 
>> sense, "read" alone is limiting your "portability".  So portability in the 
>> meaning of POSIX is out of the question.
> 
> Pardon me?  `read' is a feature of every historical shell and standardized
> by Posix.  The bash implementation is a superset of Posix.
> 
> Chet
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

My bad.  I was under the impression `read` was a Bourne shell-only thing and 
not standardized under POSIX.

Re: operators available in bash versions

[Mike Frysinger]

On Monday 30 November 2009 06:12:35 Gerard wrote:
> I need to know if " $(< " also works on Bash < 4.

it's been around for pretty much all time.  bash-2 had it for sure, and that 
is ancient.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: IFS handling and read

[Marc Herbert]

Chris F.A. Johnson a écrit :
>Why should it be the last element of a pipeline that is executed in
>the current shell and not the first?


Because that's POSIX' choice?


Because the last element is the last one in the data stream. So it feels
more natural to get everything from the last element rather than side
effects from the first and stdout from the last.



>Suppose that I have a group of commands that sets some variables
>and outputs information to the screen, for example (this is much
>oversimplified):

Thanks for the example. I find this less common than using "read".

Re: IFS handling and read

[pk]

Marc Herbert wrote:

> Chris F.A. Johnson a écrit :
>>Why should it be the last element of a pipeline that is executed in
>>the current shell and not the first?
> 
> 
> Because that's POSIX' choice?

No, POSIX allow either behavior. In fact, it allows any behavior ranging 
from running all parts in their own subshells, to running all parts in the 
current shell.

Re: IFS handling and read

[pk]

pk wrote:

>> Because that's POSIX' choice?
> 
> No, POSIX allow either behavior. In fact, it allows any behavior ranging 
> from running all parts in their own subshells, to running all parts in the 
> current shell.

"...each command of a multi-command pipeline is in a subshell environment; 
as an extension, however, any or all commands in a pipeline may be executed 
in the current environment. All other commands shall be executed in the 
current shell environment."

Re: operators available in bash versions

[Greg Wooledge]

On Mon, Nov 30, 2009 at 11:15:38AM -0500, Mike Frysinger wrote:
> On Monday 30 November 2009 06:12:35 Gerard wrote:
> > I need to know if " $(< " also works on Bash < 4.
> 
> it's been around for pretty much all time.  bash-2 had it for sure, and that 
> is ancient.

It doesn't exist in bash 1.14.7, which is the oldest version I have
available.  It does exist in 2.04, which is the second oldest I have.

Re: IFS handling and read

[Greg Wooledge]

On Mon, Nov 30, 2009 at 04:21:33PM +, Marc Herbert wrote:
> Chris F.A. Johnson a écrit :
> >Why should it be the last element of a pipeline that is executed in
> >the current shell and not the first?
> 
> Because that's POSIX' choice?

Because that's what Korn shell does.  (But not pdksh, last time I checked.)

Re: operators available in bash versions

[Mike Frysinger]

On Monday 30 November 2009 12:12:17 Greg Wooledge wrote:
> On Mon, Nov 30, 2009 at 11:15:38AM -0500, Mike Frysinger wrote:
> > On Monday 30 November 2009 06:12:35 Gerard wrote:
> > > I need to know if " $(< " also works on Bash < 4.
> >
> > it's been around for pretty much all time.  bash-2 had it for sure, and
> > that is ancient.
> 
> It doesn't exist in bash 1.14.7, which is the oldest version I have
> available.  It does exist in 2.04, which is the second oldest I have.

bash-2 was released over a decade ago and for doing any realistic work, that 
is the same as 'all time'.  realistically, you're going to run into 
portability problems with the tools run in the script rather than the script 
itself.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: <( error

[Antonio Macchi]

Based on your question, I'm guessing you're in bash 3.2 or earlier, where


$ echo $BASH_VERSION
3.2.39(1)-release

$ cat /etc/issue
Debian GNU/Linux 5.0 \n \l




your "hd <(echo -en \\0{0..3}{0..7}{0..7})" is expanded as if you had typed
"hd <(echo -en \\) <(echo -en \\0001) <(echo -en \\0002) ..." and
runs into the FD exhaustion issue Chet already described.



thanks for this and your previous post.
bye

Re: operators available in bash versions

[Greg Wooledge]

On Mon, Nov 30, 2009 at 12:35:32PM -0500, Mike Frysinger wrote:
> On Monday 30 November 2009 12:12:17 Greg Wooledge wrote:
> > On Mon, Nov 30, 2009 at 11:15:38AM -0500, Mike Frysinger wrote:
> > > On Monday 30 November 2009 06:12:35 Gerard wrote:
> > > > I need to know if " $(< " also works on Bash < 4.
> > >
> > > it's been around for pretty much all time.  bash-2 had it for sure, and
> > > that is ancient.
> > 
> > It doesn't exist in bash 1.14.7, which is the oldest version I have
> > available.  It does exist in 2.04, which is the second oldest I have.
> 
> bash-2 was released over a decade ago and for doing any realistic work, that 
> is the same as 'all time'.  realistically, you're going to run into 
> portability problems with the tools run in the script rather than the script 
> itself.

Funny thing, how all those scripts I have to write for the machine with
bash 1.14.7 don't count as "realistic"

Though you're right about the toolset being the main issue.  I had
to find a way to express things for the older version of GNU date
(from sh-utils, before coreutils was called coreutils) on that box.
Fortunately, my needs weren't very complex.

Re: operators available in bash versions

[Antonio Macchi]

Gerard wrote:

I apologize for asking what is probably a dumb question, but where can
I find a definitive listing of what features are available in each
version of Bash.

For example, I only have access to Bash-4 on my system. I need to know
if " $(< " also works on Bash < 4. I also have a few questions
regarding array handling.

I am running FreeBSD-7.2 and installed Bash via ports.




could this be a good way to achive this?


$ wget http://ftp.gnu.org/gnu/bash/bash-2.0.tar.gz
--2009-11-30 19:08:52--  http://ftp.gnu.org/gnu/bash/bash-2.0.tar.gz
Resolving ftp.gnu.org... 140.186.70.20
Connecting to ftp.gnu.org|140.186.70.20|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1349450 (1.3M) [application/x-tar]
Saving to: `bash-2.0.tar.gz.1'

100%[==>] 1,349,450285K/s   in 
5.6s


2009-11-30 19:09:09 (237 KB/s) - `bash-2.0.tar.gz.1' saved [1349450/1349450]

$ tar -zxf bash-2.0.tar.gz bash-2.0/doc/FAQ -O | grep "What.s new in 
version"

10) What's new in version 2.0?
10) What's new in version 2.0?

$ wget http://ftp.gnu.org/gnu/bash/bash-3.0.tar.gz

[etc.]

Re: IFS handling and read

[Jan Schampera]

Lhunath (Maarten B.) schrieb:

> My bad.  I was under the impression `read` was a Bourne shell-only
thing and not standardized under POSIX.

(not personal for you only, I see that very often)

It would be nice if people actually read POSIX before they talk about it.

Jan

Re: operators available in bash versions

[Allodoxaphobia]

 (Didn't have the OP on the server to followup to. SRI)

> On 30 Nov 2009, at 12:12, Gerard wrote:
>> 
>> I apologize for asking what is probably a dumb question, but where can
>> I find a definitive listing of what features are available in each
>> version of Bash.
>> 
>> For example, I only have access to Bash-4 on my system. I need to know
>> if " $(< " also works on Bash < 4. I also have a few questions
>> regarding array handling.
>> 
>> I am running FreeBSD-7.2 and installed Bash via ports.

You can, doncha know, install ports into $HOME?
Ergo, you could install bash 3.x and one or more earlier versions
in $HOME/bin/ and test your scripts to your heart's content.

I found the install 'tricks' via Google, but I don't remember the 
keywords I succeeded with beyond 'freebsd' and 'ports' now...

I successfully installed `alpine` in my FreeBSD shell account 
at a time when the SysAdmin only had `pine` installed.  WFM

HTH & GL
Jonesy
-- 
  Marvin L Jones| jonz  | W3DHJ  | linux
   38.24N  104.55W  |  @ config.com | Jonesy |  OS/2
* Killfiling google & banter.com: jonz.net/ng.htm