It seems that actually no one has ever tried to develop this mod using a UNIX system. Not a huge problem, but the UNIX gradle wrapper doesn't have execute permissions. If I ever commit, my commit will include that fix.

I developed it on a Xubuntu and a Kubuntu, but I normally don't use the gradle wrapper ever, I use the system gradle

I have only used the gradle wrapper for setup. Is it possible to run gradle setupDecompWorkspace in the project folder as well?

yes this works fine

That's awesome... If I commit ever I'll still commit with execute privileges on the owner of that file. That way other UNIX users who don't use system gradle to do stuff without having to worry about something else.

Execute permissions are from shell, basically unix's version of a registry.
Linux sometimes has this issue as well, but not as much because you have to do most everything as superuser anyway, so you're usually in a mode that gives you full control.

You will have to give the file, and perhaps the folder as a whole execution permissions manually. Or alternatively activate administration mode in the terminal before executing gradle functionality.

Even if you do manage to fix this for you, if you upload it, nothing related to this issue actually changes because you only modified your own shell, not the actual files.
And if you put a superuser call in the gradle file, that will break windows support.

One alternative is you could make a sh file or the like, similar to my setup batch file, and have the superuser calls in that.

Let me explain what I did.
Cloned this repo, and ran ./gradlew setupDecompWorkspace
That gave me a permission denied error, so I ran chmod u+x gradlew to allow me to run it. It was that simple.
So what you're saying is that git won't store my changes to the file permissions even though I made them? I don't see anything here that requires superuser priveleges, and generally you want to avoid using those on large programs if at all possible.

Yeah gradle doesn't store execute permissions. it's a shell thing, your changes aren't actually stored in the file itself.
Superuser is just another way around needing execute permissions. (it's basically the lazy way)

Personally, chmod is a better solution. But both do work. Also, why is gradle storing permissions? That should be git's job. That was also why I was curious, because git showed that gradlew had changed after I ran chmod, which would indicate that git would store that change...

Neither of them are storing permissions, unix shell is.
sorry, I should have been more clear on that. I forgot git and unix can both be referred to as "shell"

Alright. I guess that makes sense. Git doesn't then store file permissions, Linux inferrs them based on filetype?

In some cases it's filetype, in most cases it's path, or URI.
In the case of chmod u+x, it's URI, and only for the specific user that ran it.