Well, obviously this works much better over a real shell, but you seem to have figured that out pretty quickly. ;)

But to give you an answer to your question, it could be done. If I would have to implement something like it (at gunpoint), I would use rather a file upload button. That's probably the best way to have it arriving more or less intact to the server.

From then on, you either use cron to check for incoming files every so many minutes and do automatic builds, or you decide it can't be dirty enough for you and you spawn your building scripts or compiler directly from perl. This surely would require setting higher timeouts for your apache daemon and removing all resource limitations you might have. Also, the web browser would have keep the connection open for as long as is needed. And your cgi program would have to be pretty smart about redirecting the right file handles (STDIN, STDOUT, STDERR, perhaps more) so you'd actually see some of what happens on the other side (unless you are a flawless and *very* bored programmer, which might explain your question, too).

Ofcourse, I should not forget to mention the possible security implications of letting people compile and run code on your computer remotely, over the web. It just might not be the sanest thing to do from public computer halls over unencrypted (unauthenticated) connections.

And after you worked around all this, I don't think you would be happy with the end result, either. HTTP and CGI are just not meant to do certain things (efficiently, reliably) which need a whole different approach and environment. To be more precise, a http connection is typically short and stateless, making it very difficult to control and steer long running processes directly.

But you could write a build system or daemon and let http be one of the interfaces to it. If you have a long running process that can be executed independently of HTTP connections to control whatever it is you want to do, possibilities open up.

By the way, perhaps you could try out one of the Linux boot cds. If you have trouble finding one that has a full building environment, make one yourself. With vfat support, you could use free space on the windows drives; and you can easily scp (ssh), rsync or email your programs home. In fact, IIRC, there was a way to mount a server as a local filesystem through ssh. Implement that on your boot cd, and you automatically have easy access to your files at home, too. It takes a bit of work, but once you have something that works, you can just pop the cd in pretty much any computer and have your whole environment customised to your needs.

Not as easy as the ssh option, but you wouldn't have to use windows at all. =)

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.