Re: [ANN] lpty 0.8-1

[Gunnar Zötl <gz@...>]

Hi Ed,

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.

Gunnar