On Mon, 23 Jan 2006 03:47:11 -0800
Brian Harring <ferringb@g.o> wrote:

> On Mon, Jan 23, 2006 at 11:16:03AM +0100, Marius Mauch wrote:
> > On Wed, 11 Jan 2006 12:39:03 -0800
> > Brian Harring <ferringb@g.o> wrote:
> > 
> > > Regex you've got there allows for pulling the wrong text- recall,
> > > ebd originally was doing grep based filtering (regex).  Had to
> > > rewrite that in a major hurry since bash syntax (specifically
> > > here ops) forces you to track state/constructs rather then just a
> > > regex...
> > 
> > Not really an issue in this case. First the code bails out if more
> > than one match is found, so unless the metadata assignment is NOT
> > found by it we don't get the wrong info. 
> > Also a mismatch in this special is so
> > extremely unlikely that honestly I don't really care about it,
> > especially as this is a one time conversion (might be different if
> > I'd have added the on the fly extraction).
> 
> Re-read that statement.  It's a one time conversion- meaning we
> better get it right the first time, else the user's data is
> effectively corrupted.  Forcing a full regen from the saved
> environment is not a solution for fixing past corruptions either.
>
> If it were on the fly extraction, I wouldn't care quite as much- but 
> the fact this is an untracked change to the users data means we *do* 
> need to cover corner cases.

Can't follow your thinking here. As said, the code won't corrupt any
data, at worst it will tell the user that it couldn't extract some keys
(and even that only if there would be such a stupid case which itself
has a chance of like 10^-10 or so, or can you name a single case?).
Also with on the fly extraction (note: not talking about on the fly
conversion here) it would be a more serious problem as it woldn't be
time limited.

> I know you want this in, but it has to be done *right* covering all 
> known corner cases for it- I already wrote the tool that handles the 
> corner cases properly, use it, don't adhoc a solution that 
> re-introduces the potential gaps.

So what package contains filter-env then?

> Aside from that, if the code is in debate (as this is), I really 
> don't think it should get slid into svn 2 weeks later effectively 
> unchanged- didn't write that original email just for the hell of it :)

As said, I disagree with your assessment of the situation. If you can
name a single case where the code "breaks" or filter-env hits the tree
I might reconsider, but not before.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.