When moving my make.sh file into /usr/local/bin it wouldn’t run from terminal by typing ‘make.sh’ even though it worked in /bin and /usr/bin. echo $PATH gives me this:
/home/cocytusdedi/.local/bin:/home/cocytusdedi/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin
So it looks like it should be running but I can’t figure out why it’s not, moving my own binary called main into /usr/local/bin also allowed me to call it from the terminal. It just says: ‘bash: /usr/bin/make.sh: No such file or directory’ when I try and call it from terminal, and I did confirm it worked when calling using it’s full file location.
Edit: I also did use chmod +x to make sure it was executable.
You can try hash -r to clear bash’s PATH lookup cache.
I’d also check that the SELinux context is set properly with ls -lZ. Generally, if you make a file in your home directory, you should copy rather than move it into a system directory so that its context is set appropriately for the new location.
I don’t really get why, but using cp instead of mv fixed the problem as you suggested. ls -lZ revealed that after using copy instead of move it had root on it instead of my username. I don’t really get what that means though, does it mean it runs as root whenever it runs instead of as my user?.
It’s not strictly necessary, but it’s good practice for files in system directories to be owned by root.
More important is the SELinux context. A file created in /usr/local/bin will have system_u:object_r:bin_t:s0, whereas something created in your home directory might have unconfined_u:object_r:user_home_t:s0. That context stays with the file when it’s moved, and so some confined system services may not be able to access it.
None of this should have prevented access by your own user, but it’s still prudent to make it correct.