Program works standalone, but not when run from os.run()

I have recently have gotten into the world of computercraft and have been working on a personal operating system. When I try to execute a lobby program for paint from the gui program, all works until the lobby program executes shell.run("paint os/images/" .. keystrokes) . I tested the program from the terminal with os/programFiles/Paint/executable and all functions worked. I have noticed similar patterns with other programs that are coming from the gui. In the case of the Paint lobby program, when a button is hit to execute the above shell command, it returns either the length of the argument for paint or "executable:3: attempt to index ? (a nil value)". As I said before, it is not a simple case of forgetting to define a variable, it works when I don't execute it from the gui program via os.run.

Things to note:
1) The GUI program halts its while loop when launching a program.
2) Works when run from the terminal.

Code:
Paint Lobby: http://pastebin.com/vFqh75BF
Gui: http://pastebin.com/skpEE0ee

Any help is much appreciated.

to do a shell.run it is shell.run(<program name>,<argument 1>,<argument 2> .etc)

do
shell.run("paint","os/images/" .. keystrokes)

It still doesn't work even with the modified shell command. Any other ideas?

danielcbailey, on 08 June 2016 - 05:22 PM said:

I have recently have gotten into the world of computercraft and have been working on a personal operating system. When I try to execute a lobby program for paint from the gui program, all works until the lobby program executes shell.run("paint os/images/" .. keystrokes) . I tested the program from the terminal with os/programFiles/Paint/executable and all functions worked. I have noticed similar patterns with other programs that are coming from the gui. In the case of the Paint lobby program, when a button is hit to execute the above shell command, it returns either the length of the argument for paint or "executable:3: attempt to index ? (a nil value)". As I said before, it is not a simple case of forgetting to define a variable, it works when I don't execute it from the gui program via os.run.

Things to note:
1) The GUI program halts its while loop when launching a program.
2) Works when run from the terminal.

Code:
Paint Lobby: http://pastebin.com/vFqh75BF
Gui: http://pastebin.com/skpEE0ee

Any help is much appreciated.

iirc this is because you need to give an environment to os.run (you don't have to, but to access some API's you do).

DannySMc, what environment do you recommend?

The usual way is to use {shell = shell, multishell = multishell} for the environment table.

Ok, I modified the os.run for the paint lobby program and it still has an error. The line of code for it: os.run({shell = shell, multishell = multishell}, "os/programFiles/" .. listFileData[1] .. "/executable")

Unfortunately I am met by the same issue again in my file viewer when I try to use shell.run for various tasks. Solving the Paint lobby issue should pave the way to solve the file viewer ones. Any other thoughts? Perhaps other environment variables?

I was looking more into the shell API and it does need to be loaded into the program. I have tried any environment variables including the ones you guys suggested. How would I go about loading it with something like os.loadAPI()?

danielcbailey, on 09 June 2016 - 02:31 AM said:

I was looking more into the shell API and it does need to be loaded into the program. I have tried any environment variables including the ones you guys suggested. How would I go about loading it with something like os.loadAPI()?

You don't load the shell API "into programs" and os.loadAPI() won't handle it. But you don't need to and it doesn't need to; you simply need to ensure that the existing shell table exists in the current environment table.

That is to say, you either do:

os.run({shell = shell, multishell = multishell}, "os/gui")

… or you use the function built to handle it all for you:

shell.run("os/gui")

If you're still having trouble, edit the modified code into your paste and quote the error.

It worked, thank you! It turned out my startup file was using os.run with {} set to the environment, so the environment of the gui was superficial as well.