Ian Jackson wrote: >Yes, we do need something like this. > >Properties that it needs to have include (and not all of these are >true of your proposal), in no particular order: > >1. Questions may need to be `independent' of any particular package. > >2. Only a particular package can determine which questions need to be >asked in what order; in particular, following questions can depend on >the previous ones. This means that we can't specify the questions in >advance in a file. Instead, we have to put the information in >command-line arguments to the query program.
Are there any scripts that actually build their questions? Isn't it usually (always?) the case that the question is in the script as a text string, though the logic may skip it? Where parameters are needed, I should like to be able to pass them in, so that the question database would have to contain something like a printf format string. If the questions are out in the database, they can much more easily be internationalised; is this a goal of the project? > >3. Questions should have a `name' that is textual (not numeric), and >is separate from the prompt string. Given 1. the name should probably >have a hierarchical structure. Given 2. there needs to be a way to >put arbitrary `parameters' into the `name'. The way I wrote the script, it could have any arbitrary text, except for the delimiter character; I thought of it as a number, because that means less typing. >4. There should be a way to specify how `important' it is that a >question be asked, and an environment variable or something to specify >how willing we are to prompt, so that we can tune the level of >prompting. Presumably this is when there is no default in the database? Is this to enable the installation scripts to ask only `important' questions, whereas a different context would prompt more readily? I think I need some meaningful names attached to the different levels of prompting so that I can understand how you are thinking. >5. The interface should be suitable for changing the UI later (eg, >plain-text, fullscreen text, X or whatever). > >6. The database format used to cache answers should be editable by >humans. > >7. The query program should be the same as the retrieve-question >program, so that the database of previous questions acts as a cache >for the user. My script was using different calling names to distinguish its function; I think I can do better by duplicating file pointers, but I haven't really thought how yet. I need to distinguish output of the question to the screen from output of the answer to the calling script. > >8. If the query program cannot prompt but the arguments say it needs >to then it should indicate this with a nonzero exit status, which will >(hopefully) cause the script to bomb out. > >9. Valid responses should be specified by regexp (preferably a >reasonably fully-featured regexp like a Perl one) not a glob. It would probably be better to write in Perl than shell script; then it would be easier to achieve this. > >10. Metacharacters in prompts and data should work completely >correctly. Again, this is more difficult to achieve in shellscript; however, what should metacharacters be doing in this context? Correctness implies a specification to measure against. Are we talking about shell or regexp metacharacters here? -- Oliver Elphick [EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID 32B8FAA1 ======================================== "But as it is written, Eye hath not seen, nor ear heard, neither have entered into the heart of man, the things which God hath prepared for them that love him." I Corinthians 2:9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
