os.run() return path

I can't find any earlier suggestions on this…

Wouldn't it be useful to make os.run() return the return path from the executed program? Right now os.run simply returns true when the pcall to the program (encapsulated in a function) succeeds. Wouldn't it be useful to make it do:

return true, err

Where 'err' is the result from the pcall to to the program (the return values from your program).

I could think of some uses and it doesn't seem to have any disadvantages.

Good idea. I can see how this could be used. Of course you could just make your own os.run, unless you need it to work with other people's programs.

There's no reason that it wouldn't work with other people's programs, though. Unless you mean you need it to be called from their programs, and again, it wouldn't do any good unless you also inserted an extra variable to catch the return of the error message, in which case you can easily change the shell.run function for your own while you're at it.

I meant that you could just make your own os.run() that returns the value from the program, unless you want other people to be able to write their code with the return statement in mind, so you can do something with it without them having to write it specifically for your OS (or whatever your running it from).

…oh, you mean…so other people…no I don't know what you mean. I must have a nail in my coffin or something.

An example of what I believe faubiguy means is the following. Imagine that I make a program that I want to serve as both a program and an 'API'. One of the solutions would be to make the program return the relevant values. Now, to capture the variables I could make a modified version of 'os.run' (it's changing one line really) so that I could do:

local succes,p1,p2,p3 = os.run(_G,'myProgram')

But if I want to share this program with others and I want to give them the possibility to use it in their code like this. Then they all need this modified version of os.run() aside from my program. That sort of defeats the purpose.

You can just redefine the os.run in the file or in an associated API, though. I mean, I like the idea of the core function being redefined to have this behavior, and would definitely use the extra parameters in some of my stuff, but I don't see the insuperable difficulty here.

Would be nice if shell.run() did that as well.

Yeah…I use a shell.run command on my remote turtles, and right now they don't really give much useful feedback about whether the program worked or not (and, of course, if you order it to run a program that requires console input then it's stuck until I can get to it, but that's hardly fixable). Both would be useful.

ChunLing, on 26 October 2012 - 05:14 AM said:

Yeah…I use a shell.run command on my remote turtles, and right now they don't really give much useful feedback about whether the program worked or not (and, of course, if you order it to run a program that requires console input then it's stuck until I can get to it, but that's hardly fixable). Both would be useful.

you could make a emergency function that runs parallel and allows you to kill the running process or update programs

very ruff example non tested psudo code

local function = prog()
   shell.run(program)
end
local function bootLDR()
   while true do
    event,sendID,message,distance = os.pullEvent("rednet_message")
    if sendID == authorised and message == "NEW BIOS" then
    repeat
    event,sendID,newBOIS = os.pullEvent("rednet_message")
    untill sendID == authorised
   file = fs.open
  file.write(startup,newBIOS)
  fiel.close
   os.reboot()
   end
end

parallel.waitForAll(prog,bootLDR)

ChunLing, on 26 October 2012 - 04:45 AM said:

You can just redefine the os.run in the file or in an associated API, though. I mean, I like the idea of the core function being redefined to have this behavior, and would definitely use the extra parameters in some of my stuff, but I don't see the insuperable difficulty here.

Well, I never said there was a difficulty. First off, this was just an example, there might be more complex uses. Second, the user will always either have to implement a custom os.run function or use an additional API. Third, it's just changing one line in bios.lua, what's the harm? :D/>/>

@BST Oh, that's an idea. I usually don't use the parallel functions, but in this case it would be very helpful.

It was someone else who said there was some essential problem…I'm still not sure I know what the essential problem was. Having this in the core API seems like a pretty good idea, anyway.

I sorta liked being a "Lua Pro", "Lua Maniac" sounds like a step in the wrong direction (not that I'll challenge the accuracy of the assessment). It's only a matter of time before I become a "Lua Repeat Offender", and then a "Lua Predator". Then I'll probably become a "Lua Serial Predator"…or worse.