9 replies to this topic

[HPWebcamAble]

I've been trying to NOT do this:

shell.run("program","arg1")

Doing this instead:

os.run( {} , "program" , "arg1")

But it seems that programs launched with os.run, and {} as the environment, won't have access to the
shell API, maybe even other important APIs.

I tried passing _G instead. Don't do that. It doesn't help. In fact its worse.


Multishell has the same problem:

multishell.launch( {} , "program" , "arg1" )

program won't have access to shell API, maybe other


Is there a 'correct' way to do it? Should I be passing 'getfenv()'?
Should I just use 'shell.run' instead of 'os.run' / multishell ?

[flaghacker]

os.run({shell = shell}, "prog", "arg1")

This should somewhat work.

The shell is a special api that's only available to programs ran with the shell. This way you pass your own shell api to the other program.

I believe shell.getRunningProgram won't work, but you could try that out yourself.

Most of the time there's not really a good reason to not use shell, could you elaborate?

edit: typos

Edited by flaghacker, 16 August 2015 - 05:16 AM.

[valithor]

flaghacker, on 16 August 2015 - 05:10 AM, said:

os.run({shell = shell}, "prog", "arg1")

This should somewhat work.

The shell is a special api that's only available to programs ran with the shell. This way you pas your own shell api to the other program.

I believe shell.getRunningProgram won't work, but got could try that out yourself.

Most of the time there's not really a good reason to not use shell, could you elaborate?

ninja'd

Guess I will just build on to what you said. The only other api that you would not have access to by default would be the multishell api, so it would be smart to also include that.

-- From the original post I was writing
The only two apis that would be effected by this in regular CC would be shell and multishell api solely due to how they are loaded. All other apis are loaded using os.loadAPI, but shell and multishell are just simply programs that are running that have declared global variables, which is why you can normally use them in other programs run within them.

Edited by valithor, 16 August 2015 - 05:15 AM.

[HPWebcamAble]

flaghacker, on 16 August 2015 - 05:10 AM, said:

Most of the time there's not really a good reason to not use shell, could you elaborate?

A select few programs that come with CC use the shell API, and there are obviously a ton of user made ones that do.
The program I'm working on is a File explorer (which you should be looking forward to ), and it needs to be able to run programs

EDIT: You are correct, shell.getRunningProgram returns the 'parent' program, not the one the 'parent' program started. Though that should be easy to fix.

Edited by HPWebcamAble, 16 August 2015 - 05:34 AM.

[flaghacker]

HPWebcamAble, on 16 August 2015 - 05:28 AM, said:

flaghacker, on 16 August 2015 - 05:10 AM, said:

Most of the time there's not really a good reason to not use shell, could you elaborate?

A select few programs that come with CC use the shell API, and there are obviously a ton of user made ones that do.
The program I'm working on is a File explorer (which you should be looking forward to /> ), and it needs to be able to run programs

It seems you missed one of my "not"s in my post. I was asking why you don't use shell.run in place of os. run .

[Lignum]

shell.run can be summarised as:

os.run({ shell = shell, multishell = multishell }, ...)

Since this is exactly what you're doing, why not use shell.run for the job?

[HPWebcamAble]

flaghacker, on 16 August 2015 - 06:33 AM, said:

It seems you missed one of my "not"s in my post. I was asking why you don't use shell.run in place of os. run .

Oops, I must have been tired

Lignum, on 16 August 2015 - 01:32 PM, said:

Since this is exactly what you're doing, why not use shell.run for the job?

I believe I heard using shell.run isn't really a good practice, though I can't remember why.

I did actually get mutlishell and os.run working, I'll use those for now unless I encounter any weird problems.

[Lyqyd]

Nah, using shell.run is perfectly fine if that's what you're needing to do. Especially since using shell.run would actually allow shell.getRunningProgram to return meaningful results, unlike the cobbled-together workaround that does essentially the same thing.

[HPWebcamAble]

Lyqyd, on 16 August 2015 - 11:40 PM, said:

Nah, using shell.run is perfectly fine if that's what you're needing to do.

Hm, noted. I guess I'll go back to using it instead of os.run and multishell explicitly.

I guess the 'bad practice' I was thinking about is when newbs use it to loop their program.

[flaghacker]

HPWebcamAble, on 16 August 2015 - 11:58 PM, said:

Lyqyd, on 16 August 2015 - 11:40 PM, said:

Nah, using shell.run is perfectly fine if that's what you're needing to do.

I guess the 'bad practice' I was thinking about is when newbs use it to loop their program.

It's mostly about "unexperienced players" using

shell.run("clear")

to clear the screen. I remember I did it at one point to

Edited by flaghacker, 17 August 2015 - 09:42 AM.