Bill Ricker <bill.n1...@gmail.com> writes: > Code fuzzed on the ENV value *after* the function definition should > not have been accepted at all. Executing it at function def time is a > bug.
What troubles me most about this is how the bit of code that reads in environment variables sends the function body string into the top of the general purpose parser. I.e. the start symbol is not function_body but the start symbol for the whole shell language. I don't know yacc/bison very well. Is there no easy way to call into the generated parser asking for a different start symbol, something lower down in the grammar? Or else to share code between two generated parsers? This seems the fundamental issue to me. That and the fact that what's called is "parse_and_execute" not "parse_and_collect_parse_tree" or whatever. The patches workaround this from outside, which is fine for fixing in a hurry, but what's the long term fix? How it is now looks really messy and hackish IMO. And the amount of C string manipulation in that latest function name prefix/suffix protection patch makes me nervous. But I'm not a regular C programmer, so maybe that's par for the course for such things. -- Mike Small sma...@panix.com _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss