Use sh alternatives and fix change directory in building shell scripts

[r6915ee]

This pull request changes the shell scripts to now use shebangs and to properly change the working directory.

The shebangs point to /usr/bin/env, which is usually required by UNIX operating systems to be in that exact location, and uses sh as that program's first argument. This forces the program to prefer a sh variant in any location; that is, bash, zsh, and the like.

The lone cd line has been simplified to now use "$(dirname "$0")/..", which now uses a relative path to the script to go into the script's parent directory. This resolves multiple issues with the prior version, such as going to the parent directory of the working directory and, when using Nix shells, somehow entering /tmp.

[NexIsDumb]

this is the same thing ive done yesterday before resorting to that line i ended up with

although the only reason why i didnt end up using this, is because if u try to run it with a terminal inside the building folder (or by double clicking the file) it'll work, but it wont work if u try to run it from the main project folder as it'd try to go one folder back from the main project one

so what i did was to get the path of the current script (in both batch and shell) and then from there going one folder up

although you say in some occasions it doesnt work? never experienced it, what can i do to recreate the issue that you just said?

[r6915ee]

although the only reason why i didnt end up using this, is because if u try to run it with a terminal inside the building folder (or by double clicking the file) it'll work, but it wont work if u try to run it from the main project folder as it'd try to go one folder back from the main project one

so what i did was to get the path of the current script (in both batch and shell) and then from there going one folder up

I typically use the source builtin when running shell scripts. I'm not sure how different it works from simply proposing the shell script as an argument, but in Bash, it still simply goes up to the parent directory of the current process when using that builtin.

although you say in some occasions it doesnt work? never experienced it, what can i do to recreate the issue that you just said?

Sometimes, it will (quite interestingly) go to the /tmp directory, at least on Linux (NixOS) using the above builtin (although this may be due to the Nix shell session I had during testing for another pull request, but still).

When directly running the command that is used as the input for cd, I'm not on my PC at the moment to test this, but from what I remember the output seems to be malformed to some degree. There was certainly a newline in the string returned, if I remember correctly, but I'll again need to test that to show that result.

In summary, considering the environment I have at the moment, perhaps a good way to try and reproduce the issue is maybe share either the current Nix shell configuration I have and test it from there or make a draft pull request, and then use the source builtin in Bash from both the repository root and the unmodified shell script.

[r6915ee]

I managed to record a proper terminal session using asciinema. I'll see if I can create a draft pull request that includes the (incomplete, due to an outdated Haxe version being in Nixpkgs at the moment, that being 4.3.6) proper Nix shell configuration used here.

[NexIsDumb]

thats so odd
i use linux too now and it has never happened

[moxie-coder]

thats so odd i use linux too now and it has never happened

could vary by distro maybe, especially since they’re using NixOS in this case

[r6915ee]

thats so odd i use linux too now and it has never happened

My guess is that it's perhaps an issue with the Nix shell configuration's shell hook, which is typically run on Nix shell startup under special properties, such as additional commands. That might be what's causing the issue on my end, and in the terminal session. It could also theoretically be dirname.

As I've said in #771, I can perhaps reconfigure the shell hook to run the command line program directly so that the issue is avoided there.

Even then, though, the original script only seemed to get the parent directory of the working directory, so that needs to be sorted out.

[r6915ee]

"$(dirname "$0")/.." appears to work when executing it on my end, as well as prefixing . . I'll commit it in real quick, and update the initial pull request comment.

[r6915ee]

I forgot to update the pull request metadata; I'll do so now.

[NexIsDumb]

you're right, im getting those annoying errors aswell
my arch distro is even creating a temp sh file😭

[NexIsDumb]

"$(dirname "$0")/.." appears to work when executing it on my end, as well as prefixing . . I'll commit it in real quick, and update the initial pull request comment.

i'll test it soon, thank you very much

[NexIsDumb]

it works perfectly fine outisde of the building folder, inside of it and also by double clicking it, tysm!!