I would think you could do everything with a single script, and a bunch of distinct sql templates stored as plain text files; you could put commentary in the templates so that when the arg inventory on the command line happens to be inappropriate for the given template file, the poor user can get a clue as to what the correct usage should be. Just add the template file name as the first arg in the command usage.
This approach could save a lot of typing on the command line, since the sql template files can contain actual field names (things that don't change when the query is used repeatedly), and you only need args (and placeholders in the templates) for conditional values (things that are different just about every time the query is used).
But having said that, I look at your example again and scratch my head -- I don't understand what you're really doing... The command line args are supposed to provide the table name and field names, and the conditional values ('336%', etc) are hard coded? That seems backwards.
I wonder if this might explain why you have a (perhaps large) number of distinct "SQL generator" scripts -- the part that should be parameterized is scripted, and vice-versa.
(And I wonder what this has to do with being unix-oriented.)
In reply to Re: Getting the DATA section of one module in the import() of another
by graff
in thread Getting the DATA section of one module in the import() of another
by princepawn
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |