Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix OpenOS '/bin/sh cmd' failing due to lack of env table #3196

Open
wants to merge 4 commits into
base: master-MC1.7.10
Choose a base branch
from

Conversation

0x0ade
Copy link

@0x0ade 0x0ade commented Dec 25, 2019

/bin/sh.lua should be able to execute a command passed as an argument, but currently fails to do so in interactive shells as sh.execute (in /lib/sh.lua) expects an environment table as the first parameter:

image

That environment table is given when running commands in the interactive shell, but is missing from the non-interactive sh.execute call.

Meanwhile, /bin/source.lua passes an environment table as the first argument to /bin/sh.lua when starting the sh process manually.

As such, I've decided to add a simple check if the first parameter is a table. If it is, it's assumed to be the environment table and won't be passed on. Otherwise _ENV will be used and all arguments will be passed on.

image

This should maintain compatibility with any existing usages of /bin/sh.lua as a child process. Admittedly, I've only tested it locally by manipulating a copy of /bin/sh.lua after installing OpenOS onto an OC computer.

(Sidenote: I was not sure whether to remove the env table from the argument list, or whether to skip it when unpacking the arg list. I went with the second option as I thought it'd be preferred, given how returning does the same.)

/bin/sh.lua should be able to execute a command
passed as an argument, but failed to do so as
sh.execute (in /lib/sh.lua) expects an env table.
Meanwhile, /bin/source.lua passes said environment
table when starting the sh process manually.
cenv = cargs[1]
cargsStart = 2
end
local result = table.pack(sh.execute(cenv, table.unpack(cargs, cargsStart)))
Copy link
Contributor

@Vexatos Vexatos Dec 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be shortened a bit.

  local cenv = _ENV
  if type(cargs[1]) == "table" then
    -- sh can also run as a manually started process (see /bin/source.lua)
    cenv = table.remove(cargs, 1)
  end
  local result = table.pack(sh.execute(cenv, table.unpack(cargs)))

Also, what about using {...} instead of table.pack(...)?

Copy link
Author

@0x0ade 0x0ade Dec 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as with skipping the arg with table.unpack instead of using table.remove, I figured I'd just stick to what's already being used and used table.pack instead of {...}, mixing multiple ways to achieve the same thing in the same chunk of code.

Copy link
Contributor

@Vexatos Vexatos Dec 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are not completely identical. Using {...} would pack all arguments into a table, whereas table.pack actually also adds the additional key "n". Not that it matters in this case.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TIL 😅 anyway, I've just pushed another commit implementing your proposed changes.

Copy link
Contributor

@Vexatos Vexatos Dec 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is up to @payonel anyway.

@Vexatos Vexatos requested a review from payonel December 26, 2019 01:48
@payonel payonel removed their assignment May 15, 2021
@payonel payonel added this to the OC 1.7.6 milestone Jun 8, 2022
@payonel
Copy link
Member

payonel commented Jun 9, 2022

first of all, i greatly dislike that /bin/sh takes a table as an arg
no /bin program should ever have been written this way
we inherited this strangeness from ages ago and well, it's far too late to change it now.

@payonel
Copy link
Member

payonel commented Jun 9, 2022

nope i dont care
it just doesnt make sense to assume ENV is passed to /bin/sh
it is easy to correct this, and all my tests pass
the only way this breaks someone's code is if they call /bin/sh via loadfile
my fix corrects shell.execute and os.execute, which honestly is what everyone is using

@payonel payonel closed this in c9530ae Jun 9, 2022
payonel added a commit that referenced this pull request Sep 3, 2022
payonel added a commit that referenced this pull request Sep 3, 2022
@asiekierka asiekierka reopened this Sep 3, 2022
@asiekierka
Copy link
Contributor

Well, guess this is not so simple to fix.

@asiekierka asiekierka modified the milestones: OC 1.7.6, OC 1.8.0 Sep 3, 2022
@asiekierka asiekierka modified the milestones: OC 1.8.0, OC 1.9.0 May 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants