This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
cyanisaac's profile picture

What is the difference between shell.run() and os.run()

Started by cyanisaac, 05 January 2016 - 04:28 AM
cyanisaac #1
Posted 05 January 2016 - 05:28 AM
I don't see anything else about this and I'm very curious what the difference is, and what I want to use where.
Creator #2
Posted 05 January 2016 - 05:39 AM
You can specify a custom environment with os.run while shell.run uses _G every time. Also, shell.run makes it more compatible with the shell.
ElvishJerricco #3
Posted 05 January 2016 - 06:22 AM
As Creator said, you can specify the environment with os.run.


-- program.lua
sandboxedGlobal = 3

-- run program.lua
local env = {}
os.run(env, "program.lua")
print(env.sandboxedGlobal) -- 3

But shell.run does NOT use _G. Each shell (most people usually only have one shell open) creates its own environment that it uses between all the programs it runs. So globals a program makes when run through the shell will be accessible to any other program run from the same shell. Furthermore, using shell.run gives access to the shell API, and makes it play nicely. Programs do not have any access to the shell API when you use os.run (unless you put shell in the environment you pass, but that leads to buggy behavior).


-- shellProgram.lua
print(globalString)
globalString = shell.getRunningProgram())

-- run shellProgram.lua
globalString = "Hello!"
shell.run("shellProgram.lua") -- prints "Hello!"
print(globalString) -- prints "path/to/shellProgram.lua"

So you can a couple of things that shell.run does here. Firstly, when shellProgram.lua asked for getRunningProgram(), shell returned shellProgram, rather than something else. Secondly, they shared a globalString variable because of the shared environment. The following program would not share the globalString variable.


globalVariable = "Hello!"
shell.run("shell shellProgram.lua")
print(globalVariable) -- prints "Hello!"

That spawns another shell which runs the program and does not use the other shell's environment.
cyanisaac #4
Posted 06 January 2016 - 11:38 PM
What "buggy behavior" occurs with passing the "shell" into something with os.run? I'm a bit confused what that actually means.
KingofGamesYami #5
Posted 06 January 2016 - 11:44 PM
What "buggy behavior" occurs with passing the "shell" into something with os.run? I'm a bit confused what that actually means.

Well, for one shell.getRunningProgram will return the wrong program name, since you're passing it the shell instance that your program got.
cyanisaac #6
Posted 06 January 2016 - 11:45 PM
What "buggy behavior" occurs with passing the "shell" into something with os.run? I'm a bit confused what that actually means.

Well, for one shell.getRunningProgram will return the wrong program name, since you're passing it the shell instance that your program got.

Ah, I see. That makes sense, so basically because you aren't running things through the shell, the shell may have outdated/incorrect information. Gotcha.