Re: [bug-recutils] Proposal: utility to prompt for user input

[Jose E. Marchesi]

    > I always envisioned an interactive mode for recins (recins -I?) that
    > would perform the task you describe.  The interactive prompt could use
    > %allowed (as you hinted) but also %mandatory and the other special
    > fields to improve the user interface.
    
    How do you think the interactive mode should handle %mandatory and other
    "restrictive" fields like it? Perhaps the prompt for a mandatory field
    can say that it is mandatory, like this:
    Enter item color (mandatory):

Yeah.  Also, it could insist on a value to be entered.  Likewise, types
shall be checked and invalid entries rejected.  Also arbitrary
%constraints, and so on..
    
    Do you think the interactive mode should nag the user if they fail to
    satisfy the restrictions? Or just return an error and force them to
    enter the record again?

I think that rejecting invalid input is a sane default for an
interactive tool.  A --force option could be added to disable the checks
tho.
    
    I spent some time reading rec.h but I haven't completely wrapped my head
    around the API yet. The very rough plan I have in my head is to try to
    copy recins as much as possible: call rec_db_insert followed by
    recutl_check_integrity. What do you think?

Do you see any problem in expanding recins with an interactive mode,
instead of adding a new utility?

You will have to validate individual records, field types, and so on.
Look at the rec_int_* functions in rec.h for that.  Once the input is
validated, you can use rec_db_insert to insert the new record.  Finally,
the existing recutl_check_integrity call in recins will take care of the
database-wide data integrity.

I think that both modes (batch and interactive) can be nicely abstracted
in recins.
    
    > On the other hand, recinf is the tool supposed to provide
    > metainformation about recfiles.  It can currently emit record
    > descriptors...
    > 
    > ... but unfortunately recsel and company doesn't apply selection
    > expressions to record descriptors, so, the following won't work:
    > 
    > fields=`recinf -d -t machine $file | recsel -P %allowed`
    
    If we went this route, how would we call recins in the shell script? The
    "fields" shell variable would still require a lot of text processing in
    order to turn this:
    
    $ fields="name description"
    
    ...into this:
    
    $ recins -t machine \
    -f name -v $name \
    -f description -v $description \
    $file
    
    I actually thought about parsing the output of  `recinf -d`, and then
    building up the recins command as text before calling the shell's `eval`
    on it. That is possible currently, but it's the kind of work that I'd
    rather nobody have to do.

You are right.  An interactive mode for recins would be much better: you
would not need to build your own UI in the script.  But extracting
metainformation with recinf is very useful for other purposes.  For
example, we would not need to replicate logic in rec-mode.el to parse
types.
    
    > So, we could add selection options to recinf.  Or we could change it to
    > emit record descriptors without the % prefixes.
    
    I'm afraid I don't understand what recinf would be selecting. Can you
    explain it more?

Suppose you wanted to get a list of allowed files in a record type.  If
recinf supported field expression and output options (-P, -R, -p, etc)
we could do it this way:

$ recinf -t machine -R %allowed database.rec
name description