TCL?

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

nelson@crynwr.com (Russell Nelson) wrote:
> It would be even cooler if zplay emitted the digits as it got them.  That
> way, 'expect' could be used to control the message playback in any manner.

I'm not sure what the advantage of that would be. Currently, you
can use `zplay -D` to get a single character, `zplay -C` records a
string of digits terminated by '#' where '*' can be used to delete
the previous digits and start over. For your method, zplay and
the external program would have to run synchronously, and you would
have to use a signal to get zplay to quit if the digit(s) you want
have arrived. This might be useful if zplay had some understanding
of the voice format used (i.e. to implement `rewind' and `fast
forward'), but currently zplay was intended to do a simple job
and then exit.

If you tell me a good application, I could put it in. It wouldn't be
really complicated, but it would mess up the flow of control a bit.

> How about having zplay accept a "DTMF max length" option, and if more
> DTMF is received, it gets sent to stderr.  Then, expect could run zplay
> with that option set to zero.
> 
> Or maybe, instead of ignoring the DTMF digits if use_commands is false,
> just print them to stderr?

This wouldn't work. Unless you specify -C (use_commands), zplay will
exit as soon as it gets a DTMF digit. I was thinking that a voice 
mailbox would be easiest to use if you use single-digit codes
for most actions and multi-digit commands only if they are really
necessary, i.e. for phone numbers or access codes. 

This way, a sample menu would say something like `press 1 to repeat
this message, 2 for ...' and you could hit the digit while the
message was still playing or during the (adjustable) silence period
following it without having to press an `end' key like '#' or having to
wait through a timeout while the program is waiting if there will be
any more digits.

> Or maybe, change -D so that it causes DTMF digits to be sent to stderr
> as they're received.  Then a shell script can capture them using
> "zplay ... 2> /tmp/zplay.$$".

It would probably be useful to do this if both -C and -D are specified,
to avoid having both end up on stdout. But I'm not sure how zplay
should react if both are specified, either it quits after the first
digit or it doesn't. Any suggestions?

BTW, caller hangups are signalled using the return code, i.e. if
zplay returns 1, that means that the modem has detected 'b', 'd'
or 's'. You don't usually need to handle these based on the code
printed on stdout.

>    Something that is still missing, but that I'm working on, is to 
>    replace the entire answering sequence with a shell script.
> 
> How about checking for special file which, if it exists, is executed
> instead of the message-beep-record C code?

It's currently a compile-time option. Once I've got the shell script
working properly for fax and data calls, I could put it in. Until then,
I'm afraid it will just result in people complaining that vgetty
is broken if they create this file. People have already found some
very creative uses for the /etc/answer.* file...

> Gee, if you're up particularly early, you'll get this message a few
> minutes after I hit return.  But for myself, I sleep now.

:-)

If you catch me programming at 7.00 in the morning it is because I
stayed up late, not because I got up early. Are there any programmers
that are happy with a 9-to-5 (a.m. to p.m.) work schedule? 

Klaus
-- 
\ klaus@snarc.greenie.muc.de--kweidner@physik.tu-muenchen.de--2:246/55.4
\ .signature error -- quote dumped