Fix search of tools under $PATH #1236
Conversation
Due to the fact we have to have (for our tools) ./ ahead of other paths (including the tool names themselves) and also allow for a user to specify a path (even a bogus one, which if they do we will look for a proper path) and also search for installed paths, a more careful check has to be done in the find_utils() functions as otherwise it does not work when out of the repo directory. Sync copyright fixes from jparse.
|
Hopefully GitHub doesn't have any issues with this change either. If it does not then it's all good now I think. I actually saw the oddity in the debug output yesterday but as I was in the repo directory at the time it did not dawn on me as odd. The ordering issue has turned out to be a lot of fun, for funny definitions of fun. |
QUESTIONDo we need to perform the idea about looking for the source files (see GH-issuecomment-2715178275) as an additional safety check before simply executing tools out of "."? |
Nope. I replied in that comment how I did it. I just tested it again. However I can test it when it's not installed and out of the directory: though it should be fine - I'd have to give the options to the tools. |
|
Just tested with it uninstalled: as expected it required the options. See my comment there (replied to your comment a few minutes ago) where you can see out of the directory and also in the directory. |
Due to the fact we have to have (for our tools) ./ ahead of other paths (including the tool names themselves) and also allow for a user to specify a path (even a bogus one, which if they do we will look for a proper path) and also search for installed paths, a more careful check has to be done in the find_utils() functions as otherwise it does not work when out of the repo directory.
Sync copyright fixes from jparse.