Re: Interacting With Another Script
Chris Rebert
> Hi;
> There's a program (vpopmail) that has commands which, when called, request
> input ("email address", "password", etc.) from the command line. I would
> like to build a TTW interface for my clients to use that interacts with
> these commands. It's easy enough for me to get the information from a
> script, but how do I input it when these functions keep requesting
> information? I hope I've made myself clear :-}
(assuming TTW = Thru The Web; been a while since I've come across an
unknown, non-new acronym)
[Disclaimer: I know zilch about vpopmail's specifics]
Option A. Check for when the latest output looks prompt-like (e.g.
colon followed by a space; this will be program-specific and possibly
different for vpopmail) and then ask for input. For example:
1. Get new session request from client
2. Run new vpopmail process
3. Wait until prompt detected in process' output
4. Send back webpage with the output and a <form> to answer the prompt
5. Write user's response from form as input to process.
6. If read EOF, send final output back as webpage to client and close
session. Else, GOTO 3
(See also: expect)
Option B. Web pseudo-shell using AJAX. Client polls server for new
output. Client pushes new input to server at any time.
1. Get new session request from client
2. Run new vpopmail process
3. Send back webpage w/ JavaScript code
4.1. Client periodically polls server for new output via AJAX and
displays it when there is some.
4.2. Client has omnipresent <form> that on submission sends an AJAX
request to the server with the given input.
5. If get input message from client, write input to process' stdin. If
get polling message from client, do non-blocking read on the process'
output and respond with the result. If get EOF, inform client on next
poll and then close session.
Option C. The most user-friendly, and in some sense simplest, one.
Figure out the "conversation tree" vpopmail follows. Create a matching
form tree workflow, presenting multiple input fields at once. Run
vpopmail and write the appropriate input to its stdin based on the
form data. Send the output back as a webpage.
[Session management & timeouts in the preceding are left as exercises
for the implementor]
Option D. The Zen option: It seems quite probable that someone's
already written a web frontend for vpopmail
administration/configuration. Just use that. The best software is that
which you don't have to write.
Cheers,
Chris
--
Ironically, I have yet to code a webapp.
http://blog.rebertia.com
Chris Rebert
> On Wed, Mar 10, 2010 at 12:31 PM, Chris Rebert <cl...@rebertia.com> wrote:
>> Option C. The most user-friendly, and in some sense simplest, one.
>> Figure out the "conversation tree" vpopmail follows. Create a matching
>> form tree workflow, presenting multiple input fields at once. Run
>> vpopmail and write the appropriate input to its stdin based on the
>> form data. Send the output back as a webpage.
>
> prompted to enter data? That's my question ;)
There's no magical "prompt time". The process's stdin's openness to
writing is not conditional.
Just send it all the input at once with the proper newlines in place
and it should work just fine assuming the user input was valid
(barring vpopmail using some fancy terminal input malarkey like
curses).
Cheers,
Chris
--
http://blog.rebertia.com
Grant Edwards
> On Wed, Mar 10, 2010 at 8:34 AM, Victor Subervi <victor...@gmail.com> wrote:
>
>> Yeah, that was my idea. But how does the program know when it's being
>> prompted to enter data? That's my question ;)
>
> There's no magical "prompt time".
That depends on the program. Some programs that prompt for input
(particulary username/password) flush stdin before displaying each
prompt. I'm not saying the program in question does that...
> The process's stdin's openness to writing is not conditional.
That doesn't mean that data written prior to the prompt won't be
ignore.
> Just send it all the input at once with the proper newlines in place
> and it should work just fine assuming the user input was valid
> (barring vpopmail using some fancy terminal input malarkey like
> curses).
It's worth trying, but there's a slight chance it won't work.
--
Grant Edwards grant.b.edwards Yow! But they went to MARS
at around 1953!!
gmail.com
Gabriel Genellina
<victor...@gmail.com> escribió:
> There's a program (vpopmail) that has commands which, when called,
> request
> input ("email address", "password", etc.) from the command line. I would
> like to build a TTW interface for my clients to use that interacts with
> these commands.
I know nothing about vpopmail, but can't you provide all the required
information by some other means? Command line arguments, a configuration
file, perhaps there is an API to call some internal functions? Faking an
interactive session would be my last option.
--
Gabriel Genellina
alex23
> > There's a program (vpopmail) that has commands which, when called, request
> > input ("email address", "password", etc.) from the command line. I would
> > like to build a TTW interface for my clients to use that interacts with
> > these commands.
The Pexpect[1] module is pretty much aimed at doing exactly this.
lkcl
i also made some patches to telnetlib.py back in 2000, creating an
expectlib.py and then using that in telnetlib.py. the code is still
in python's bug tracker, and no fucker has integrated it, despite it
still being valid, relevant and useful, in ten years since.
the code basically creates a base class from which the "old"
telnetlib derives, but it also provides an additional class
TelnetPopen which, as you might expect, can be used to run python
popen and then use _all_ of the functions in telnetlib which should
never have been hard-coded as specifically being associated with the
Telnet class (hence why i moved them to expectlib.py).
it's therefore possible to use it to do ssh "as if" it was telnet
(remember to use the -t option to stop terminal translation, and
remember to use TelnetPopen because otherwise you have to patch ssh to
accept passwords on the command-line!)
in order to avoid clashes with telnetlib.py, i often rename it to
telnetlib2.py and i believe i've regularly published them in other
free software projects, so you should find it with a search for
"telnetlib2.py". if you can't specifically find the two modules, let
me know, and i'll make them available somewhere.
l.