[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] lpty 0.8-1
- From: Gunnar Zötl <gz@...>
- Date: Tue, 17 Aug 2010 19:40:19 +0200
you may have noticed that the purpose of lpty is very different from
that of luasocket. I have written lpty with a single purpose in mind: to
be able to control other command line programs. Pls keep that in mind
with my following comments to your suggestions.
On 17.08.2010 17:47, Ed wrote:
I think better is luasocket-alike interface:
1. read() can be renamed to receive()
btw, read/send pair is strange.
I don't think so. I have actually thought about the naming scheme for
these functions, and considering that you read from the master side of
the pty also what you yourself write to it rather than just receive what
the child app sends, using read() makes a lot of sense to me. I will
agree that send() is a matter of taste, but everything you send() to he
master side of a pty will reach a child app, even if it is read back
from the master side before the child app is started. So I chose that
name rather than write(), which was my first name for that function. I
am quite happy with the names, not likely to change them.
2. In luasocket only one receive function return error message too:
If successful, the method returns the received pattern. In case of
error, the method returns *nil* followed by an error message
Yep, that is one thing I actually consider for the next version. There
are additional thoughts on this as a timed out read also returns nil,
but is not considered an error.
3. Your version of send() did not understand partial writes, in luasocket:
client:*send(*data [, i [, j]]*)*
Yes, this is a result of the purpose of the lib. Note also that send()
has a timeout argument as well, you would need to fit that into your
argument list, resulting in either the need to always specify i and j if
you want a timeout or always specify a timeout if you want i and j.
If you need to handle large amounts of data sent to a client program,
you can do partial sends yourself as send() returns the amount of bytes
written to the pty. You would have to do a bit of string munging, though.
In case of error, the method
returns *nil*, followed by an error message, followed by the index of
the last byte within [i, j] that has been sent.
send() returns nil if it has not sent anything (i.e. if the send()
operation timed out). Your proposal is a change of the semantics of the
return values of the function. However, as with read() I am considering
returning nil + error message in case of errors instead of throwing them.
4. You define sendok() and readok(), but sometimes better is check
several file descriptors in one select/poll call.
luasocket provide getfd() function for this.
This is a bit out of scope for this lib. As I mentioned, this is about
controlling programs from lua. I might think about such a thing, should
the need arise to control hordes of programs simultaneously from one
script, but currently I don't see it.
Allow me to pull in the suggestion you made in another mail:
> I need to run pppd over pty from Lua script.
> pppd do not need stin/stdout redirection (pty name must be specified
> in parameters).
> I think this code must be optional:
> dup2(ttyfd, 0);
> dup2(ttyfd, 1);
> dup2(ttyfd, 2);
Again, out of scope. But I also think that it would not hurt your
application, you can still pass the ttyname to your pppd, as long as it
does not also write to stdout. Also, if it is not passed a tty name,
pppd will use stdin/stdout, at least that's what the manual says. So you
should be safe there.
I hope this did not come over as too negative. Thanks for your
suggestions, even though they are mostly directed at problems that do
not lie within the intended scope of lpty. You are very welcome to take
the source and make the changes you need. The license is very permissive.