On Wed, 2009-08-26 at 09:29 -0400, Rob Crittenden wrote: > Martin Nagy wrote: > > On Tue, 2009-08-25 at 16:39 -0400, Rob Crittenden wrote: > >> This adds 2 new options to the installer so the user can select the > >> numeric starting point for uidnumbers and gidnumbers. > >> > >> This also adds a new option to the template system, eval(). You can have > >> the python interpreter evaluate a statement and include the result in > >> the template output. > >> > >> rob > > > > So, first I see this: > >> -uidNumber: 999 > >> -gidNumber: 1001 > >> +uidNumber: $UIDSTART > >> +gidNumber: $GIDSTART > > > > And then later I see this: > >> -dnaNextValue: 1100 > >> +dnaNextValue: eval($UIDSTART+1) > > Right, $UIDSTART is the uid for the admin user. > > > [snip] > >> -dnaNextValue: 1100 > >> +dnaNextValue: eval($GIDSTART+3) > > $GIDSTART = admins group > $GIDSTART+1 = ipauserse group > $GIDSTART+2 = editors group > > So the next available gid is $GIDSTART+3. Now we could leave it as > $GIDSTART in the dna config and it would do the right thing at runtime > if that would be less confusing. > > > > > This seems to be inconsistent, is this intentional? More inconsistencies > > I can see are in the command line option parser where you use 1100 as > > default for both UIDSTART and GIDSTART. In the man page you state the > > default is 1000 for both. > > Yeah, that is a goof. It should be 1000. > > > For the evaluation code, I feel it is a tad more complex than it has to > > be. Also, the pattern seems to be too greedy. I'd suggest that you use > > the sub() function instead, here's an example: > > > >>>> str = "Something, something, something, eval(foo). Something, > > something, something, eval(bar)." > >>>> foo = "dark side" > >>>> bar = "complete" > >>>> pattern = re.compile('(eval\s*\(([^)]*)\))') > >>>> pattern.sub(lambda x: eval(x.group(2)), str) > > 'Something, something, something, dark side. Something, something, > > something, complete.' > > > > This also allows eval() to work more times on one line (also notice the > > [^)]* which makes sure we don't accept something like "eval(foo) bar)". > > I'm also of the opinion that we do abort the installation if the eval() > > fails, because that would be a clear bug. If we keep it quiet we might > > see a more cryptic error instead. > > I see what you are getting at but your code doesn't work. It doesn't > actually evaluate the lines (I specifically want to do math). I should > also note that the re module doesn't count parenthesis so it will almost > always not do the right thing with nested parens, this is why I do it > line-by-line.
Ah, sorry, had a bug in there. The sub function should have been called like this: >>> pattern.sub(lambda x: str(eval(x.group(2))), string) and the math will work (you have to use a variable with a different name than I used before). I forgot to wrap the eval() statement into str(). Since you mentioned the paren counting, I also realized that a better pattern would be '(eval\s*\(([^()]*)\))'. But this still creates a problem, if you use "eval(foo + (2 * 4))" then the code will try to evaluate "foo + ". This is really a messy business. I'm not sure how to solve this simply without the use of a parser. But still, your code would be IMO even more dangerous. > > Sure, we can quit the install if you'd prefer. > > rob Martin _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel