[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bash-bug
Subject:    Re: Unexpected behavior & Core dumps
From:       Chet Ramey <chet () nike ! ins ! cwru ! edu>
Date:       2003-10-07 1:35:52
Message-ID: 031007013552.AA99348.SM () nike ! ins ! cwru ! edu
[Download RAW message or body]

> Machine Type: i686-pc-linux-gnu
> 
> Bash Version: 2.05b
> Patch Level: 0
> Release Status: release
> Configuration: --enable-static-link --without-gnu-malloc

Thanks for the report, and for the detailed examples.

> Description:
> 	Multiple examples. Appears to be only a few problems.
> 	(1) After: unset IFS, IFS may not be redefined and initialized from
> 	    a variable.  Define and initialize from a literal works.

I can't reproduce this, and there doesn't seem to be any evidence of it
in the script.  Adding the assignment `IFS=$oIFS' where the comment
indicates doesn't result in any misbehavior.

> 	(2) Parser state error(s) demonstrated by:
> 		${VarName- FuncInvoke} and ${VarName:- FuncInvoke} broke
> 		${VarName+ FuncInvoke} and ${VarName:+ FuncInvoke} works
> 		${SparseArray='Literal'} walks array expecting element to contain a command.

There doesn't appear to be any evidence of this in the attached script,
either.  There are several comments based on incorrect assumptions which
could be the cause of the report.

> 	(3) Everything else involves sparse arrays
> 		Inconsistant element counting;
> 		${#SparseArray[@]} counts content and null-content elements
> 		${SparseArray[@]:Digit:Digit} counts content elements only

Thanks; there are indeed inconsistencies.  I have corrected them.

> 	(4) Various and sundray core-dump constructs when used on sparse arrays.

Thanks again.  The cause of the core dump has been fixed.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
						Live...Laugh...Love
Chet Ramey, ITS, CWRU    chet@po.cwru.edu    http://tiswww.tis.cwru.edu/~chet/



[prev in list] [next in list] [prev in thread] [next in thread]