1 |
On Mon, 23 Jan 2006 03:47:11 -0800 |
2 |
Brian Harring <ferringb@g.o> wrote: |
3 |
|
4 |
> On Mon, Jan 23, 2006 at 11:16:03AM +0100, Marius Mauch wrote: |
5 |
> > On Wed, 11 Jan 2006 12:39:03 -0800 |
6 |
> > Brian Harring <ferringb@g.o> wrote: |
7 |
> > |
8 |
> > > Regex you've got there allows for pulling the wrong text- recall, |
9 |
> > > ebd originally was doing grep based filtering (regex). Had to |
10 |
> > > rewrite that in a major hurry since bash syntax (specifically |
11 |
> > > here ops) forces you to track state/constructs rather then just a |
12 |
> > > regex... |
13 |
> > |
14 |
> > Not really an issue in this case. First the code bails out if more |
15 |
> > than one match is found, so unless the metadata assignment is NOT |
16 |
> > found by it we don't get the wrong info. |
17 |
> > Also a mismatch in this special is so |
18 |
> > extremely unlikely that honestly I don't really care about it, |
19 |
> > especially as this is a one time conversion (might be different if |
20 |
> > I'd have added the on the fly extraction). |
21 |
> |
22 |
> Re-read that statement. It's a one time conversion- meaning we |
23 |
> better get it right the first time, else the user's data is |
24 |
> effectively corrupted. Forcing a full regen from the saved |
25 |
> environment is not a solution for fixing past corruptions either. |
26 |
> |
27 |
> If it were on the fly extraction, I wouldn't care quite as much- but |
28 |
> the fact this is an untracked change to the users data means we *do* |
29 |
> need to cover corner cases. |
30 |
|
31 |
Can't follow your thinking here. As said, the code won't corrupt any |
32 |
data, at worst it will tell the user that it couldn't extract some keys |
33 |
(and even that only if there would be such a stupid case which itself |
34 |
has a chance of like 10^-10 or so, or can you name a single case?). |
35 |
Also with on the fly extraction (note: not talking about on the fly |
36 |
conversion here) it would be a more serious problem as it woldn't be |
37 |
time limited. |
38 |
|
39 |
> I know you want this in, but it has to be done *right* covering all |
40 |
> known corner cases for it- I already wrote the tool that handles the |
41 |
> corner cases properly, use it, don't adhoc a solution that |
42 |
> re-introduces the potential gaps. |
43 |
|
44 |
So what package contains filter-env then? |
45 |
|
46 |
> Aside from that, if the code is in debate (as this is), I really |
47 |
> don't think it should get slid into svn 2 weeks later effectively |
48 |
> unchanged- didn't write that original email just for the hell of it :) |
49 |
|
50 |
As said, I disagree with your assessment of the situation. If you can |
51 |
name a single case where the code "breaks" or filter-env hits the tree |
52 |
I might reconsider, but not before. |
53 |
|
54 |
Marius |
55 |
|
56 |
-- |
57 |
Public Key at http://www.genone.de/info/gpg-key.pub |
58 |
|
59 |
In the beginning, there was nothing. And God said, 'Let there be |
60 |
Light.' And there was still nothing, but you could see a bit better. |