Standard IO streams in Ruby
in [Ruby]
|
Prev: REXML - controlling whitespaces and inserting CR
Next: how to check if some object is included in some module?
From: Jatin Kumar on 1 Aug 2010 14:06 In my rails controller, I am doing the following : @output = `g++ j.cpp -o "prog" && ./prog` This gives the output in the @output variable which i can display in my view. But the above works only if the j.cpp is correct and doesn't expect any user input. How can I use the stdin/stderr and stdout streams here so that : If the user has to give input, I open a dialog box on the view with a textfield where he/she can enter the input, and the program continues to execute. If there are any errors in the file, then I should be able to get the errors and display them to the user. I tried doing this : @output = `g++ j.cpp -o "prog" && ./prog| tee prog` This allows me to enter the user input at the server command prompt (the server log...i don't know what do we call it), but I want it to be entered in a textfield in the view. In short, how can I get control of stdin, so that whenever the stdin waits for some user input, i get to know that it is waiting for the user input and then i can show the user a text field and get the user input to be passed in the stdin stream. Let me know if there's a doubt in the question. -- Posted via http://www.ruby-forum.com/.
From: David Masover on 2 Aug 2010 22:58 On Sunday, August 01, 2010 01:06:59 pm Jatin Kumar wrote: > In my rails controller, I am doing the following : > > @output = `g++ j.cpp -o "prog" && ./prog` Why are you compiling it every time? From some of your questions, it seems like you're going to let the user enter source code, then compile it and run it. Is that true? If so, do you realize how insanely dangerous that is? > If the user has to give input, I open a dialog box on the view with a > textfield where he/she can enter the input, and the program continues to > execute. You can't do that from inside a Rails controller. You can capture IO with popen or open3: http://www.ensta.fr/~diam/ruby/online/ruby-doc- stdlib/libdoc/open3/rdoc/classes/Open3.html But that doesn't solve your problem by itself -- you need to send data to and from the browser interactively. That means you at least need AJAX, and possibly Comet or Web Sockets, combined with some sort of background processing. > I tried doing this : > > @output = `g++ j.cpp -o "prog" && ./prog| tee prog` That would overwrite your program with the output of your program. Is that really what you want to do? man tee > In short, how can I get control of stdin, so that whenever the stdin > waits for some user input, i get to know that it is waiting for the user > input You can't do that either, not really. The best you can do is always provide that text field, and show the user standard output and standard error, so they can see the program prompting them -- and detect the program exiting, so you can remove the text field. If you want to be able to do this efficiently, you're going to need to do a lot of reading. It basically boils down to these two options: http://en.wikipedia.org/wiki/Comet_(programming) http://www.websockets.org/ But however you implement the updates -- you could always just poll -- but you're still going to need one of these: http://www.tobinharris.com/past/2009/3/9/6-ways-to-run-background-jobs-in- rubyonrails/ There are probably newer/better alternatives to those, too...
From: Jatin Kumar on 3 Aug 2010 08:56 >> In my rails controller, I am doing the following : >> >> @output = `g++ j.cpp -o "prog" && ./prog` > > Why are you compiling it every time? I am not compiling it every time, only when the user clicks on the compile/execute button that i provide in the view. > From some of your questions, it seems like you're going to let the user > enter > source code, then compile it and run it. Is that true? If so, do you > realize > how insanely dangerous that is? Yes, I am exactly doing that. Why does it sound to you insanely dangerous?? Could you elaborate a little on that.? >> If the user has to give input, I open a dialog box on the view with a >> textfield where he/she can enter the input, and the program continues to >> execute. > > You can't do that from inside a Rails controller. You can capture IO > with > popen or open3: > > http://www.ensta.fr/~diam/ruby/online/ruby-doc- > stdlib/libdoc/open3/rdoc/classes/Open3.html > Yes, i know that I have to capture IO for that. Thanks for the link. Really appreciated. > But that doesn't solve your problem by itself -- you need to send data > to and > from the browser interactively. That means you at least need AJAX, and > possibly Comet or Web Sockets, combined with some sort of background > processing. Yes, I am using AJAX. I will look into Comet or Web Sockets, but I have no idea of a web socket and how do they work? How can I use them in here? >> I tried doing this : >> >> @output = `g++ j.cpp -o "prog" && ./prog| tee prog` > > That would overwrite your program with the output of your program. Is > that > really what you want to do? > > man tee > No, I am not overwriting the program with the output. There's probably something wrong but i can take care of it. >> In short, how can I get control of stdin, so that whenever the stdin >> waits for some user input, i get to know that it is waiting for the user >> input > > You can't do that either, not really. The best you can do is always > provide > that text field, and show the user standard output and standard error, > so they > can see the program prompting them -- and detect the program exiting, so > you > can remove the text field. Got your point. > If you want to be able to do this efficiently, you're going to need to > do a > lot of reading. It basically boils down to these two options: > > http://en.wikipedia.org/wiki/Comet_(programming) > http://www.websockets.org/ > But however you implement the updates -- you could always just poll -- > but > you're still going to need one of these: > > http://www.tobinharris.com/past/2009/3/9/6-ways-to-run-background-jobs-in- > rubyonrails/ Thanks for the links. I will read them all and will get back to you if i need help. > There are probably newer/better alternatives to those, too... Newer / Better alternatives ??? I could not think of a better way. If you have something in your mind that can ease the above process, that would be great. Thanks for all your help. -- Posted via http://www.ruby-forum.com/.
From: David Masover on 3 Aug 2010 21:55
On Tuesday, August 03, 2010 07:56:48 am Jatin Kumar wrote: > > From some of your questions, it seems like you're going to let the user > > enter > > source code, then compile it and run it. Is that true? If so, do you > > realize > > how insanely dangerous that is? > > Yes, I am exactly doing that. Why does it sound to you insanely > dangerous?? > Could you elaborate a little on that.? Because any user could compile and run this: #include <unistd.h> int main() { execlp("rm", "rm", "-rf", "/", NULL); } The user might have limited privileges, but they'd certainly be able to wipe out any file they have access to, on any filesystem that's mounted. Unless you've thought through your sandboxing quite a bit, this is a Bad Idea. And if you are trying to sandbox it, you'd better keep up to speed on local vulnerabilities of all kinds. Even if you do all that, you still need to make sure you block it from making network connections, or you could become an open spam relay, among other things. Now, if you know what you're doing, all of the above should be obvious to you. If so, I apologize -- you may have a perfectly legitimate reason for doing this, and you may have already taken the necessary precautions. > > But that doesn't solve your problem by itself -- you need to send data > > to and > > from the browser interactively. That means you at least need AJAX, and > > possibly Comet or Web Sockets, combined with some sort of background > > processing. > > Yes, I am using AJAX. I will look into Comet or Web Sockets, but I have > no idea of a web socket and how do they work? How can I use them in > here? So, AJAX is just a way for the browser to initiate a conversation with the server. Rails is designed to be stateless, just like the Web -- that means, as soon as you render a response for the client, you're done, it's as if your program has ended and is ready to start again for the next response. You can run programs in the background, and there are many ways to do this. Then your program would be running in the background, but there'd be no communication between it and the user interface. You could have the browser periodically check back via AJAX -- this is called "polling" -- but then, you have a problem. If you poll too fast, you generate a lot of unnecessary network traffic. If you poll too slowly, it takes too long for a response to come back. Comet is a neat hack to turn AJAX into the opposite -- a "push" mechanism. It uses "long polling", which you can read about elsewhere, but the net result is that as soon as the server has data ready (so, as soon as your program sends more text to STDOUT), that data is sent to the client. Web sockets are a new technology to build the idea of a two-way communication into the browser -- so that either the server or the client can immediately tell the other when there's some new information. In other words, Comet is basically a really hackish way of emulating what WebSockets will do properly. To simplify things, you may want to start with polling (it's easier to do), but the pieces are still roughly the same -- you still need to run the program in the background and capture the output, only now, you just need to store it somewhere your Rails controller can get to. > >> I tried doing this : > >> > >> @output = `g++ j.cpp -o "prog" && ./prog| tee prog` > > > > That would overwrite your program with the output of your program. Is > > that > > really what you want to do? > > > > man tee > > No, I am not overwriting the program with the output. There's probably > something wrong but i can take care of it. Now that I think of it, you'd probably get lucky -- 'tee prog' might open the file first, then gcc would remove that file and overwrite it. But again, read the manual -- 'man tee' -- tee is for sending output both to standard output and to a file. Is that what you're trying to do here? I don't see why you're using tee at all. > > There are probably newer/better alternatives to those, too... > > Newer / Better alternatives ??? I could not think of a better way. If > you have something in your mind that can ease the above process, that > would be great. Nothing in particular, all I mean is that it's been awhile since I've looked at message queues, but I do remember there was a lot of active research the last time I looked. So, I couldn't tell you what's best, but the basic components haven't changed. You'll need: - Some way to fire off a background task. - A separate server (outside of Rails) to do Comet or WebSockets. - Some custom client-side JavaScript to connect to that server. - Some way for the background task to send updates to that server. The last time I did something like this, I used custom JavaScript code (with maybe a little jQuery), rubystomp, a custom Rack-based Comet server (borrowed some code from somewhere, can't remember where), and Rails for the rest of the application. I think I also used open3. However, I was also only running a certain limited number of commands remotely, and I was only allowing administrators to run them. I also never got this application to production, and as it would only have ever been used by administrators, it didn't need to be particularly efficient -- so I have no idea how well those pieces (rubystomp, etc) actually perform. |