(Reposted per Francis'' request.)
Now that the changes to make the input descriptor blocking on a
popen''ed
process are in:
How can we then close the input descriptor w/o closing the output one? i.e.,
if you''ve popen''ed a process and want to send_data to it, then
close the
connection yet still receive data until the child process closes its
standard output ( i.e., our input), how can we do that?
It would be great if we could do something like this, and receive the
expected result:
require ''eventmachine''
module CatHandler
def post_init
send_data "this is a test\n"
close_connection_after_writing
end
def receive_data data
print data
end
def unbind
EventMachine::stop_event_loop
end
end
EventMachine::run {
EventMachine::popen("cat", CatHandler)
}
Likewise, I''ve run into some issues because EM::popen only lets the
caller
access the standard output stream of the subprocess and no others (in
particular, standard error).
Today I compensate for all of these deficiencies by doing something kludgey
like:
EventMachine::popen(%[sh -c "echo #{data} | #{command} #{args.join}
2>&1"])
Observation: Because they both involve Connection objects, a popen is
treated the same as a network connection, despite the fact that in some very
important ways they are quite different: popens have different attributes
(pid and exit status vs. peer IPs and ports) and have access to more than
one output stream. In addition, unlike TCP sockets, the application
designer often may want to access the output that''s provided after the
program''s input stream has been flushed and closed.
Perhaps it''s time to subclass Connection so that we can take advantage
of
the differences while impacting existing socket code as little as possible?
Also: For consistency''s sake it would be nice if EM put a
process'' return
status into a Process::Status object, like the backtick operator does (the
latter places it into $?).
Best regards,
--Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071210/7060d288/attachment.html
Question: Have there been any recent bug fixes that make it ''important'' for us to upgrade to the latest version of EM, if we use the C version? wish-list item: One thing I''d like to be able to see is the ''reason'' that an unbind is called--kind of like ''get last error message''--was it graceful? Was it connection reset by peer? Was it ''actively refused'' as some are? Anyway just some thoughts. Take care. -Roger On Dec 10, 2007 2:12 PM, Michael S. Fischer <michael at dynamine.net> wrote:> (Reposted per Francis'' request.) > > Now that the changes to make the input descriptor blocking on a popen''ed > process are in: > > How can we then close the input descriptor w/o closing the output one? i.e., > if you''ve popen''ed a process and want to send_data to it, then close the > connection yet still receive data until the child process closes its > standard output ( i.e., our input), how can we do that? > > It would be great if we could do something like this, and receive the > expected result: > > require ''eventmachine'' > > module CatHandler > def post_init > send_data "this is a test\n" > close_connection_after_writing > end > > > def receive_data data > print data > end > > def unbind > EventMachine::stop_event_loop > end > end > > EventMachine::run { > EventMachine::popen("cat", CatHandler) > } > > Likewise, I''ve run into some issues because EM::popen only lets the caller > access the standard output stream of the subprocess and no others (in > particular, standard error). > > Today I compensate for all of these deficiencies by doing something kludgey > like: > > EventMachine::popen(%[sh -c "echo #{data} | #{command} #{args.join} 2>&1"]) > > Observation: Because they both involve Connection objects, a popen is > treated the same as a network connection, despite the fact that in some very > important ways they are quite different: popens have different attributes > (pid and exit status vs. peer IPs and ports) and have access to more than > one output stream. In addition, unlike TCP sockets, the application > designer often may want to access the output that''s provided after the > program''s input stream has been flushed and closed. > > Perhaps it''s time to subclass Connection so that we can take advantage of > the differences while impacting existing socket code as little as possible? > > Also: For consistency''s sake it would be nice if EM put a process'' return > status into a Process::Status object, like the backtick operator does (the > latter places it into $?). > > Best regards, > > --Michael > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >-- -Roger Pack For God hath not given us the spirit of fear; but of power, and of love, and of a sound mind" -- 2 Timothy 1:7
On Dec 10, 2007 6:50 PM, Roger Pack <rogerpack2005 at gmail.com> wrote:> Question: Have there been any recent bug fixes that make it > ''important'' for us to upgrade to the latest version of EM, if we use > the C version?Read the ChangeLog. It''ll tell you what major changes have been made since the prior release.> > > > wish-list item: > One thing I''d like to be able to see is the ''reason'' that an unbind is > called--kind of like ''get last error message''--was it graceful? Was > it connection reset by peer? Was it ''actively refused'' as some are? > Anyway just some thoughts.This is one of those good ideas I wish I had had a year and a half ago. Adding a parameter to unbind now will break code all over the place. I''ve already started a precedent I seriously dislike, by making the status of a child process visible from within an unbind handler. I suppose an alternative would be to define a different callback. Perhaps #unbind2. The reactor could detect whether unbind2 is defined and call it instead of unbind. Or it can call both. I know. Uuuugly. Anyone have a better idea? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071211/f4ec7460/attachment.html
From: Francis Cianfrocca> > Adding a parameter to unbind now will break code all over the place. > I''ve already started a precedent I seriously dislike, by making the > status of a child process visible from within an unbind handler. > > I suppose an alternative would be to define a different callback. > Perhaps #unbind2. The reactor could detect whether unbind2 is defined > and call it instead of unbind. Or it can call both. > > I know. Uuuugly. Anyone have a better idea?Would it be possible to check the arity of #unbind before calling it, and only pass the paramaters if it''s expecting them? if handler.method(:unbind).arity == 0 handler.unbind else handler.unbind(status, and_such) end Regards, Bill
On Dec 10, 2007 10:46 PM, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> On Dec 10, 2007 6:50 PM, Roger Pack <rogerpack2005 at gmail.com> wrote: > > One thing I''d like to be able to see is the ''reason'' that an unbind is > > called--kind of like ''get last error message''--was it graceful? Was > > it connection reset by peer? Was it ''actively refused'' as some are? > > Anyway just some thoughts. > > > > This is one of those good ideas I wish I had had a year and a half ago. > Adding a parameter to unbind now will break code all over the place. I''ve > already started a precedent I seriously dislike, by making the status of a > child process visible from within an unbind handler. > > I suppose an alternative would be to define a different callback. Perhaps > #unbind2. The reactor could detect whether unbind2 is defined and call it > instead of unbind. Or it can call both. > > I know. Uuuugly. Anyone have a better idea? >I still think my suggestion for subclassing Connection is a good idea, and would keep a lot of programs from breaking. A call to popen could yield a PipeConnection, which is a subclass of Connection. Then we could have all the nice behaviors we want from pipes but leave TCP/UDP connections alone. Best regards, --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071210/22933a02/attachment.html
> I know. Uuuugly. Anyone have a better idea?The only thing that comes to mind is the ability to query the object for its exit status def unbind print self.get_exit_status end that type of thing.
On Dec 11, 2007 12:08 AM, Michael S. Fischer <michael at dynamine.net> wrote:> I still think my suggestion for subclassing Connection is a good idea, and > would keep a lot of programs from breaking. A call to popen could yield a > PipeConnection, which is a subclass of Connection. Then we could have all > the nice behaviors we want from pipes but leave TCP/UDP connections alone. >While that''s a good idea in general, it doesn''t really solve the problem here. Existing programs which use popen and expect unbind without arguments would break. I think the suggestion of checking unbind''s arity and having a new unbind(why) when unbind''s arity is 1 across the board would be nice. For example, I''d really like that parameter for use with TCP sockets. Right now if EM.connect fails, then unbind is called, but I have no way to differentiate that between whether the connection to the server completed and immediately closed, among other things. It''d be nice to get unbind(CONNECTION_FAILED) or unbind(CONNECTION_CLOSED) or something to that effect. -- Tony Arcieri ClickCaster, Inc. tony at clickcaster.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071211/d8bc2805/attachment-0001.html
On Dec 11, 2007 7:02 PM, Tony Arcieri <tony at clickcaster.com> wrote:> On Dec 11, 2007 12:08 AM, Michael S. Fischer <michael at dynamine.net> wrote: > > > I still think my suggestion for subclassing Connection is a good idea, > > and would keep a lot of programs from breaking. A call to popen could > > yield a PipeConnection, which is a subclass of Connection. Then we could > > have all the nice behaviors we want from pipes but leave TCP/UDP connections > > alone. > > > > While that''s a good idea in general, it doesn''t really solve the problem > here. Existing programs which use popen and expect unbind without arguments > would break. > > I think the suggestion of checking unbind''s arity and having a new > unbind(why) when unbind''s arity is 1 across the board would be nice. > > For example, I''d really like that parameter for use with TCP sockets. > Right now if EM.connect fails, then unbind is called, but I have no way to > differentiate that between whether the connection to the server completed > and immediately closed, among other things. It''d be nice to get > unbind(CONNECTION_FAILED) or unbind(CONNECTION_CLOSED) or something to that > effect. >I basically like these ideas and it''s clear we need to do something to solve this problem. It''s a little ironic, because the bias in the original API design was to extreme simplicity. Minimum number of arguments, minimum amount of stuff for programmers to understand and remember. This is where you hit the limits of that strategy. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071212/594791e3/attachment-0001.html
On Dec 12, 2007 6:19 AM, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> > It''s a little ironic, because the bias in the original API design was to > extreme simplicity. Minimum number of arguments, minimum amount of stuff for > programmers to understand and remember. > > This is where you hit the limits of that strategy. :-) >While I share your bias based on my own experience, I''m not sure that a rich API is necessarily harder to grok than a simple one. IMO what often makes complex APIs hard to learn are (1) inconsistency w/o a good reason and (2) lack of coherent documentation, examples and explanations. (This is what drove me away from Twisted - even the O''Reilly book is totally useless.) I think that, even with a richer API, EventMachine can easily succeed in the marketplace so long as plenty of secondary materials are available to the potential user. The mailing list is a good start, but a good book, constantly updated as EM evolves, would probably be of tremendous benefit. Best regards, --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071212/a44872e0/attachment.html
From: Michael S. Fischer> > Now that the changes to make the input descriptor blocking on a > popen''ed process are in: > > How can we then close the input descriptor w/o closing the output > one? i.e., if you''ve popen''ed a process and want to send_data to > it, then close the connection yet still receive data until the > child process closes its standard output ( i.e., our input), how > can we do that? > > It would be great if we could do something like this, and receive > the expected result: > > require ''eventmachine'' > > module CatHandler > def post_init > send_data "this is a test\n" > close_connection_after_writing > end > > > def receive_data data > print data > end > > > def unbind > EventMachine::stop_event_loop > end > end > > EventMachine::run { > EventMachine::popen("cat", CatHandler) > } > > Likewise, I''ve run into some issues because EM::popen only lets > the caller access the standard output stream of the subprocess and > no others (in particular, standard error). > > Today I compensate for all of these deficiencies by doing > something kludgey like: > > EventMachine::popen(%[sh -c "echo #{data} | #{command} #{args.join} 2>&1"]) > > Observation: Because they both involve Connection objects, a popen > is treated the same as a network connection, despite the fact that > in some very important ways they are quite different: popens have > different attributes (pid and exit status vs. peer IPs and ports) > and have access to more than one output stream. In addition, > unlike TCP sockets, the application designer often may want to > access the output that''s provided after the program''s input stream > has been flushed and closed. > > Perhaps it''s time to subclass Connection so that we can take > advantage of the differences while impacting existing socket code > as little as possible? > > Also: For consistency''s sake it would be nice if EM put a process'' > return status into a Process::Status object, like the backtick > operator does (the latter places it into $?).Sorry to quote the whole message, but I wasn''t sure what to trim. To summarize the three current EventMachine::popen limitations: 1. No access to stderr as a separate stream 2. Can''t close the connection yet still receive data from the child 3. No way to obtain child exit status Hmm, I''ll add a 4th for completeness'' sake: 4. No way distinguish whether exec failed entirely to start the child #3 is presumably the easiest to remedy, modulo the ongoing discussion about HOW to return the status value. Currently PipeDescriptor::~PipeDescriptor() passes in NULL to waitpid() so the exit status is currently not being obtained. Also, this is happening in a destructor... so if it wanted to return the exit status to somebody, presumably it would have to happen through a pointer... But anyway... Shouldn''t be any huge hurdles, I''d think... #4 i''ve seen solved before (for ex. in ruby''s popen4, i think) so I guess it just depends on whether we care enough about it to bother with the extra complexity. #2 seems probably incompatible with the current implementation, because we use socketpair(), not separate read/write pipes. This gives us a single, full-duplex socket between the parent and child. I''m not sure if one can just close the "read half" of a socket and leave the "write half" open? In any case, with traditional popen(), one only gets a half- duplex connection, and must choose in advance whether one wants to write to the child, or read from it; not both. (I.e. your `cat` example wouldn''t work with the traditional popen().) #1 (access to stderr) would be nice, I''ll agree; but I''m having trouble wrapping my mind around how events from two descriptors being sent to one handler would fit cleanly into the current EM architecture (but don''t take my word for it; I''m not an expert on the EM internals... just somewhat familiar.) Regards, Bill
On Dec 12, 2007 11:31 AM, Bill Kelly <billk at cts.com> wrote:> > #1 (access to stderr) would be nice, I''ll agree; but I''m having > trouble wrapping my mind around how events from two descriptors > being sent to one handler would fit cleanly into the current > EM architecture (but don''t take my word for it; I''m not an > expert on the EM internals... just somewhat familiar.)I think a useful API implementation would simply add an extra parameter to the receive_data callback specifying the descriptor in addition to the data. Best regards, --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071212/3f5ffd3d/attachment.html
On Dec 12, 2007 3:16 PM, Michael S. Fischer <michael at dynamine.net> wrote:> On Dec 12, 2007 11:31 AM, Bill Kelly <billk at cts.com> wrote: > > > > > #1 (access to stderr) would be nice, I''ll agree; but I''m having > > trouble wrapping my mind around how events from two descriptors > > being sent to one handler would fit cleanly into the current > > EM architecture (but don''t take my word for it; I''m not an > > expert on the EM internals... just somewhat familiar.) > > > I think a useful API implementation would simply add an extra parameter to > the receive_data callback specifying the descriptor in addition to the data. > > >The descriptor is self. Unless you''re thinking of actually getting the underlying file or socket descriptor. We could add an API to EM::Connection easily enough to get at that. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071212/35082749/attachment.html
On Dec 12, 2007 1:19 PM, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> On Dec 12, 2007 3:16 PM, Michael S. Fischer <michael at dynamine.net> wrote: > > > On Dec 12, 2007 11:31 AM, Bill Kelly <billk at cts.com> wrote: > > > > > > > > #1 (access to stderr) would be nice, I''ll agree; but I''m having > > > trouble wrapping my mind around how events from two descriptors > > > being sent to one handler would fit cleanly into the current > > > EM architecture (but don''t take my word for it; I''m not an > > > expert on the EM internals... just somewhat familiar.) > > > > > > I think a useful API implementation would simply add an extra parameter > > to the receive_data callback specifying the descriptor in addition to the > > data. > > > > > > The descriptor is self. Unless you''re thinking of actually getting the > underlying file or socket descriptor. We could add an API to EM::Connection > easily enough to get at that. >In a multiple-descriptor scenario (like popen with access to both stderr and stdin channels) how could you disambiguate if the descriptor were just ''self''? Best regards, --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071212/ec6608d4/attachment.html
On Dec 12, 2007 4:29 PM, Michael S. Fischer <michael at dynamine.net> wrote:> > In a multiple-descriptor scenario (like popen with access to both stderr > and stdin channels) how could you disambiguate if the descriptor were just > ''self''? > >I may be missing something but I don''t think popen gives separate access to stderr. There''s only one socketpair between the fork parent and child. You can dup stderr onto the stdin descriptor, but then they''re both coming through the same stream. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071212/9add6e43/attachment.html
On Dec 12, 2007 2:23 PM, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> On Dec 12, 2007 4:29 PM, Michael S. Fischer <michael at dynamine.net> wrote: > > > > > In a multiple-descriptor scenario (like popen with access to both stderr > > and stdin channels) how could you disambiguate if the descriptor were just > > ''self''? > > > > > > I may be missing something but I don''t think popen gives separate access > to stderr. There''s only one socketpair between the fork parent and child. > You can dup stderr onto the stdin descriptor, but then they''re both coming > through the same stream. >I meant popen in the EM sense, not popen in the C library sense. :-) Surely there''s a C library call that provides access to all the child''s file descriptors, isn''t there? Best regards, --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071212/ac77fcac/attachment.html
From: Michael S. Fischer> > Surely there''s a C library call that provides access to all the > child''s file descriptors, isn''t there?Not that I know of? As previously mentioned, even the standard popen() is less powerful than the EM version, being half-duplex. Ruby has third-party libraries like http://popen4.rubyforge.org/ that provide such functionality. EM already rolls its own popen() ... so there''s no theoretical reason an additional pipe couldn''t be created to read the child''s stderr. The murky part for me is whether both descriptors should be associated with the same binding, and/or how the receive_data API would work as far as distinguishing between the two streams (you mentioned using an extra parameter.) Regards, Bill
On Dec 12, 2007 5:34 PM, Michael S. Fischer <michael at dynamine.net> wrote:> > > I meant popen in the EM sense, not popen in the C library sense. :-) > > Surely there''s a C library call that provides access to all the child''s > file descriptors, isn''t there? > >It could surely be done, but it''s so nonstandard (in the C library sense :-)) that I''m not sure it''s a good idea. Would it be enough for you to simply aggregate the stderr and stdin streams into one stream? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071213/4f5776da/attachment.html
On Dec 13, 2007 6:29 AM, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> > It could surely be done, but it''s so nonstandard (in the C library sense > :-)) that I''m not sure it''s a good idea. Would it be enough for you to > simply aggregate the stderr and stdin streams into one stream? >I''d prefer not to, as doing so would extinguish a feature I''d really like to implement (color coding of stderr output as a visual cue to the user). Best regards, --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071213/6406804a/attachment-0001.html
On Dec 13, 2007 10:11 AM, Michael S. Fischer <michael at dynamine.net> wrote:> On Dec 13, 2007 6:29 AM, Francis Cianfrocca <garbagecat10 at gmail.com> > wrote: > > > > > It could surely be done, but it''s so nonstandard (in the C library sense > > :-)) that I''m not sure it''s a good idea. Would it be enough for you to > > simply aggregate the stderr and stdin streams into one stream? > > > > I''d prefer not to, as doing so would extinguish a feature I''d really like > to implement (color coding of stderr output as a visual cue to the user). > >Ok, I''ll put my thinking cap on, but of course anyone who wants to take a crack at patching this is welcome to. The relevant code is in ext/em.cpp and ext/pipe.cpp. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071213/213e8bea/attachment.html
Generally the way to do that is dup2() descriptors 0, 1, and 2 before doing fork/exec rather than using libc''s popen, I believe. Hard to remember since it''s been awhile since I''ve done that sort of thing. On Dec 13, 2007 9:02 AM, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> On Dec 13, 2007 10:11 AM, Michael S. Fischer <michael at dynamine.net> wrote: > > > On Dec 13, 2007 6:29 AM, Francis Cianfrocca <garbagecat10 at gmail.com> > > wrote: > > > > > > > > It could surely be done, but it''s so nonstandard (in the C library > > > sense :-)) that I''m not sure it''s a good idea. Would it be enough for you to > > > simply aggregate the stderr and stdin streams into one stream? > > > > > > > I''d prefer not to, as doing so would extinguish a feature I''d really > > like to implement (color coding of stderr output as a visual cue to the > > user). > > > > > > Ok, I''ll put my thinking cap on, but of course anyone who wants to take a > crack at patching this is welcome to. The relevant code is in ext/em.cpp and > ext/pipe.cpp. > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >-- Tony Arcieri ClickCaster, Inc. tony at clickcaster.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071213/16ae84ba/attachment.html
On Dec 13, 2007 12:01 PM, Tony Arcieri <tony at clickcaster.com> wrote:> Generally the way to do that is dup2() descriptors 0, 1, and 2 before > doing fork/exec rather than using libc''s popen, I believe. >Yes, that''s right, but the problem is how to expose 2 different streams (stdout and stderr) to the EM::Connection object. There''s no obvious way to do it with #receive_data. There is a handful of clunky ways to do it. It''s a matter of deciding which is the best. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071213/cd2c216c/attachment.html
How about a receive_error-type callback that''s stubbed out by default? On Dec 13, 2007 10:09 AM, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> On Dec 13, 2007 12:01 PM, Tony Arcieri <tony at clickcaster.com> wrote: > > > Generally the way to do that is dup2() descriptors 0, 1, and 2 before > > doing fork/exec rather than using libc''s popen, I believe. > > > > > Yes, that''s right, but the problem is how to expose 2 different streams > (stdout and stderr) to the EM::Connection object. There''s no obvious way to > do it with #receive_data. > > There is a handful of clunky ways to do it. It''s a matter of deciding > which is the best. > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >-- Tony Arcieri ClickCaster, Inc. tony at clickcaster.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071213/b74e38eb/attachment.html
On Dec 13, 2007 12:11 PM, Tony Arcieri <tony at clickcaster.com> wrote:> How about a receive_error-type callback that''s stubbed out by default? >so for example: class X < EM::Connection def receive_data data end def receive_error data end end ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071213/94111099/attachment.html
Yes, something like that On Dec 13, 2007 10:22 AM, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> On Dec 13, 2007 12:11 PM, Tony Arcieri <tony at clickcaster.com> wrote: > > > How about a receive_error-type callback that''s stubbed out by default? > > > > > so for example: > > class X < EM::Connection > def receive_data data > end > > def receive_error data > end > end > > ? > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >-- Tony Arcieri ClickCaster, Inc. tony at clickcaster.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071213/91bcde35/attachment.html
On Dec 13, 2007 12:24 PM, Tony Arcieri <tony at clickcaster.com> wrote:> Yes, something like that > > On Dec 13, 2007 10:22 AM, Francis Cianfrocca <garbagecat10 at gmail.com> > wrote: > > > On Dec 13, 2007 12:11 PM, Tony Arcieri <tony at clickcaster.com> wrote: > > > > > How about a receive_error-type callback that''s stubbed out by default? > > > > > > > > > so for example: > > > > class X < EM::Connection > > def receive_data data > > end > > > > def receive_error data > > end > > end > > > > ? > > > > > > >I can see something like this: class X < EM::Connection def receive_data data # gets everything interleaved end def receive_stdout data def end def receive_stderr data end end and you can implement zero or more of the three. This pattern is analogous to how we do protocol handlers like LineAndText (which has #receive_line and #receive_text). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071213/e7839839/attachment-0001.html
On Dec 10, 2007 1:12 PM, Michael S. Fischer <michael at dynamine.net> wrote:> How can we then close the input descriptor w/o closing the output one? i.e., > if you''ve popen''ed a process and want to send_data to it, then close the > connection yet still receive data until the child process closes its > standard output ( i.e., our input), how can we do that? > > It would be great if we could do something like this, and receive the > expected result: > > require ''eventmachine'' > > module CatHandler > def post_init > send_data "this is a test\n" > close_connection_after_writing > end > > > def receive_data data > print data > end > > def unbind > EventMachine::stop_event_loop > end > end > > EventMachine::run { > EventMachine::popen("cat", CatHandler) > } >> Today I compensate for all of these deficiencies by doing something kludgey > like: > > EventMachine::popen(%[sh -c "echo #{data} | #{command} #{args.join} 2>&1"])Sigh. I''m afraid that even this hack is not viable. Here''s the situation: I''m building a job dispatching system that runs shell commands on behalf of users. The shell command is executed by a Expect-based wrapper that looks for password prompts and responds with the user''s password. I wanted my worker program (which uses EM) to pass the user''s password to the Expect script via standard input in order to avoid some security hazards associated with alternatives such as storing it in a file or in the environment, either of which may be observed by others logged into the system the worker runs on. However, with the aforementioned "sh -c" trick, the password appears in the output of ps(1), which is also a security hazard. For my project to be successful, I need a secure way of communicating the password to the Expect script. This means I need either EM to be able to communicate to the subprocess via standard output and close the output file descriptor yet still be capable of receiving data from the subprocess, or find some alternative that is equally secure yet EM-friendly. Any ideas? System V IPC comes to mind, but it''s not Tcl-compatible, and it''s a pretty baroque workaround. :( Best regards, --Michael
On Jan 16, 2008 12:37 AM, Michael S. Fischer <michael at dynamine.net> wrote:> > I''m building a job dispatching system that runs shell commands on > behalf of users. The shell command is executed by a Expect-based > wrapper that looks for password prompts and responds with the user''s > password. > > I wanted my worker program (which uses EM) to pass the user''s password > to the Expect script via standard input in order to avoid some > security hazards associated with alternatives such as storing it in a > file or in the environment, either of which may be observed by others > logged into the system the worker runs on. >How does your worker program get the user''s password in the first place? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080116/74b77811/attachment.html
On Jan 16, 2008 2:20 AM, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> How does your worker program get the user''s password in the first place?It gets passed to the worker via an SSL connection. Why? --Michael