revert(installer): use vim.o.sh instead of 'sh'

[gptlang]

Fixes #199

Tested on Fedora 39 with NVIM v0.10.0-dev+2606-gc0549b9c4

[github-actions]

Review Checklist

Does this PR follow the Contribution Guidelines? Following is a partial checklist:

Proper conventional commit scoping:

• For example, fix(installer): some installer bugfix

• Pull request title has the appropriate conventional commit prefix.

If applicable:

• Tested
  • Tests have been added.
  • Tested manually (steps in PR description).
• Updated documentation.

[mrcjkb]

Thanks.

This breaks the installer for Windows (see #166).
But using the configure script on Windows might not be the best idea anyway.

[mrcjkb]

I'll try to come up with a proper solution for Windows today, so I'll wait with merging for now.

[vhyrro]

This might be a risky thing to attempt, as we can't confirm that the binary will be executable on the target filesystem. When I tested (Arch), I get a "configure is not executable" error. I do think that we should use sh instead of vim.o.sh however to make sure we're running a POSIX-compatible shell :)

[gptlang]

This might be a risky thing to attempt, as we can't confirm that the binary will be executable on the target filesystem. When I tested (Arch), I get a "configure is not executable" error. I do think that we should use sh instead of vim.o.sh however to make sure we're running a POSIX-compatible shell :)

Yeah that makes sense to me. Would it make sense to hard code /bin/sh or /bin/env sh?

[mrcjkb]

This might be a risky thing to attempt, as we can't confirm that the binary will be executable on the target filesystem. When I tested (Arch), I get a "configure is not executable" error. I do think that we should use sh instead of vim.o.sh however to make sure we're running a POSIX-compatible shell :)

Yeah that makes sense to me. Would it make sense to hard code /bin/sh or /bin/env sh?

I believe /bin/sh (or just sh) is fine. /usr/bin/env is more commonly used for bash (which is less commonly available in /bin.

[NTBBloodbath]

This might be a risky thing to attempt, as we can't confirm that the binary will be executable on the target filesystem. When I tested (Arch), I get a "configure is not executable" error. I do think that we should use sh instead of vim.o.sh however to make sure we're running a POSIX-compatible shell :)

Yeah that makes sense to me. Would it make sense to hard code /bin/sh or /bin/env sh?

I believe /bin/sh (or just sh) is fine. /usr/bin/env is more commonly used for bash (which is less commonly available in /bin.

I think using /usr/bin/env sh would be best. It is the best way to maintain compatibility with any shell even in scripts for BSD systems iirc, I would go with /bin/sh but I think that would break on certain systems like Alpine, which is an edge case but it's good to keep it in mind

[mrcjkb]

This might be a risky thing to attempt, as we can't confirm that the binary will be executable on the target filesystem. When I tested (Arch), I get a "configure is not executable" error. I do think that we should use sh instead of vim.o.sh however to make sure we're running a POSIX-compatible shell :)

Yeah that makes sense to me. Would it make sense to hard code /bin/sh or /bin/env sh?

I believe /bin/sh (or just sh) is fine. /usr/bin/env is more commonly used for bash (which is less commonly available in /bin.

I think using /usr/bin/env sh would be best. It is the best way to maintain compatibility with any shell even in scripts for BSD systems iirc, I would go with /bin/sh but I think that would break on certain systems like Alpine, which is an edge case but it's good to keep it in mind

That only matters with bash, not sh.

https://stackoverflow.com/questions/53116226/what-is-the-recommended-posix-sh-shebang

[gptlang]

I would go with /bin/sh but I think that would break on certain systems like Alpine, which is an edge case but it's good to keep it in mind

Should we just assume that sh is available in PATH? I highly doubt anyone is running Neovim in a SCRATCH docker container.

Alternatively, we can continue using vim.o.sh and only fall back to sh if we find that the user isn't using a POSIX compatible shell.

I'm probably gonna move off fish over the coming days. The lack of POSIX compatibility is driving me nuts.

[mrcjkb]

Reverts 54b67ce