fesh: handle interactive prompts from drudg

[wehimwich]

Depending on the skedf.ctl set-up, drudg may want to prompt interactively, currently for tpicd interval and continuous cal control when making .prc files.

Maybe there is some way to pass those "unexpected" prompts to the user for an answer (expect?).

Maybe fesh could have command line options to set those responses or to allow the .prc dialogue to be interactive or something better ...

[dehorsley]

Perhaps it would be easier to put some automatic functionality into drudg.

Say a list of prefilled answers in eg $HOME/.drudgrc. When drudg is going to prompt, it first looks up in the file for that key, if doesn't find an answer, it prompt the user. Perhaps a command line argument to override default answers would be useful too.

[wehimwich]

I guess I don't see it, but I am happy to learn! My understanding is somewhat naive. It seems like ~/.drudgrc has three issues:

• it creates a new "control" like file that won't be in /usr2/control. I know ~/.netrc might fall in that category too, but it is probably unavoidable in the case of plog and it is not a plog control file per se (but with Stretch we might be able to move it to /usr2/control anyway, that might get the CIS people off our back on that file being in ~).

• drudg already has a control file, skedf.ctl.

• it seems like a new infrastructure (and use of it) is needed to handle ~/.drudgrc, but maybe that is easy with modern tools, even though drudg is in FORTRAN. I admit I am behind the times. If it would be manageable, that would be great.

OTOH, putting in a couple command line arguments for fesh might be a fairly surgical way to provide the functionality. There could be say -t for the tpicd interval answer and -c for the continuous cal answer. Whichever options are present, they would be used in the 'here' document input for drudg. The flaw in this approach is that it seems like you would have to have different 'here' documents, one for each combination of options. For four combinations it is just a little ugly, but obviously won't scale. Oh well.

[dehorsley]

Right. My general point is rather than pattern matching on drudg's output and trying to map out drudg's state inside fesh, it might be easier to go to the source and put some kind of automation there. The drudgrc is just a placeholder really — the configuration could go in skedf.ctl if that's a better place, though it's not a particularly "discoverable" name :)

Though expect might be an option if we don't want to fiddle with drudg.

[wehimwich]

It seems like this can be handed in three steps without modifying drudg:

• Handle one mode geo schedules
• Handle multiple mode geo schedules
• Handle astro schedules

The first is relatively easy since since the configuration at a station is usually fixed for geo and multiple modes don't need to be allowed for.

The second can probably be handled by fesh2 (using expect) if the answers to drudg probably don't change depending on the mode. However, multiple mode geo schedules are extremely rare.

The third is more difficult because the answers to drudg may depend on the band. There may be simplifying cases, most notably, stations where the answers are always the same. That still won't handle multiple modes per schedule, but as already mentioned that may be handled by fesh2. Jim also suggested having difference responses for different classes (maybe by band?) of schedules.

For the third, it will also be necessary to allow for changing the rack and recorder for eVLBI. This could probably be handled relatively easily with a command line option to insert rack/recorder selection in the drudg input.

[wehimwich]

Step 1 completed with 746f40d