Get the printed output of a program from within another program

I've wrote a program which basically allows a computer (primarily turtles) to receive wireless commands to run nearly any program (using rednet of course.) While everything works fine, I also want the program to broadcast back to the sender the "printed" output of the program. (for example, if a program prints "Hello World!", I want it to redirect the message to the device sending the command)

So, how (if possible) do I get the printed output from a program to process in another program? I am currently running it through "shell.run", but all I can get from that is a success boolean.

This is the code I'm using if that helps. Plus this code for the remote program. (excuse the strange formatting, ComputerCraft screen are a little narrow so I tried to keep lines short)

To do this, you'd need to rig the terminal of the system running the scripts to forward all display changes on to another system. You can't get the output after the script finishes execution, you need to gather it while it's running, and hijacking the term API functions is the easiest method.

This sample code should give you some idea of how to do it, assuming you can't simply use it as-is. Feel free to ask questions if you're not sure how it works.

Hmm, I would never have though of rewriting the term functions… After messing with that for awhile, I managed to come up with this for the receiver, and this to control the object.

I did have to modify the code a bit to make it work. Specifically I added the messages to a table then bulk sent them to fix a conflict with read() and rednet.receive() running at the same time, and I had to block term.redirect() from sending and adjust term.setCursorPos() positioning to fix the console output.

It still has two issues though, which I doubt are easily fixable. The first issue is that the lines do not properly wrap, their length is instead determined by the first device (in this case a turtle), and then just copied to the second (which is a pocket computer, meaning you miss part of the line). The second issue is it randomly adds the output line too early, causing it to overlap with the later lines.

These issues can indeed be fixed, though clean solutions do involve a fair bit more work to set up.

By the way, if you're not dead-set on creating the tool yourself, my nsh program would likely do what you're looking to accomplish.

The screensize issue, at least, would be simple enough to deal with - have the turtle define a window with width equal to that of the pocket system's display, then redirect to that. For bonus points, you could have the pocket computer redirect to a window with height equal to that of the turtle's screen, too; the resulting windows would have equal dimensions.

Lyqyd, on 14 July 2015 - 02:28 AM said:

These issues can indeed be fixed, though clean solutions do involve a fair bit more work to set up.

By the way, if you're not dead-set on creating the tool yourself, my nsh program would likely do what you're looking to accomplish.

At this point, I am just messing around with ComputerCraft in creative, as I have not fully decided on my list of mods to get into the survival aspects of it (all I have definitely chosen other than ComputerCraft is Tinker's Construct). My main goal was to wirelessly control computers (such as a turtle, or a password protected door), which I eventually wanted to integrate into a survival base.

As for the nsh program, it seems extremely useful, especially the "get" and "put" programs, so I will definitely find a reason to use it.

Bomb Bloke, on 14 July 2015 - 02:46 AM said:

The screensize issue, at least, would be simple enough to deal with - have the turtle define a window with width equal to that of the pocket system's display, then redirect to that. For bonus points, you could have the pocket computer redirect to a window with height equal to that of the turtle's screen, too; the resulting windows would have equal dimensions.

Yep, that fixed it. Since the height does not seem to be causing any issues (and I blocked most programs which cannot be run through a single command), I decided to leave the pocket computer at default screen height for now.

Alternatively, you could also just send the line of text trying to be written to the screen, and let the controller display it the way it wishes, which would likely be simpler?

jerimo, on 14 July 2015 - 05:23 PM said:

Alternatively, you could also just send the line of text trying to be written to the screen, and let the controller display it the way it wishes, which would likely be simpler?

Not really, since the idea is to get outputs from a program, and I am not going to rewrite all the default programs so they send their text instead of just writing it.

KnightMiner, on 14 July 2015 - 10:19 PM said:

jerimo, on 14 July 2015 - 05:23 PM said:

Alternatively, you could also just send the line of text trying to be written to the screen, and let the controller display it the way it wishes, which would likely be simpler?

Not really, since the idea is to get outputs from a program, and I am not going to rewrite all the default programs so they send their text instead of just writing it.

Assumed your be working with custom programs mainly, but yeah if you are working with the defaults more then it would be harder to do, with your own it would be as simple as overwriting the print/write function to reset.send the input then use the real function, hence the assumption
Best of luck