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)
1
Get the printed output of a program from within another program
Started by KnightMiner, Jul 12 2015 09:35 PM
lua api
8 replies to this topic
#1
Posted 12 July 2015 - 09:35 PM
#2
Posted 13 July 2015 - 01:34 AM
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.
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.
#3
Posted 14 July 2015 - 12:15 AM
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.
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.
#5
Posted 14 July 2015 - 01:46 AM
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.
#6
Posted 14 July 2015 - 04:31 AM
Lyqyd, on 14 July 2015 - 01: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.
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.
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 - 01: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.
Edited by KnightMiner, 14 July 2015 - 04:33 AM.
#7
Posted 14 July 2015 - 04:23 PM
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?
#8
Posted 14 July 2015 - 09:19 PM
jerimo, on 14 July 2015 - 04: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?
#9
Posted 15 July 2015 - 04:26 PM
KnightMiner, on 14 July 2015 - 09:19 PM, said:
jerimo, on 14 July 2015 - 04: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?
Best of luck
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users