There is no clear agreement of where in the path the opt directories "should" appear. As RMerlin explained in another thread there was a disagreement over this matter between himself and the Entware maintainer.
Yeah, there seems to be a long-standing disagreement on what the "right thing to do" should be; and it looks like we might be on different sides of that disagreement, and it certainly won't be resolved any time soon, so we'll have to agree to disagree on the pros & cons.
Whether one way or the other is "right" is academic. The reality is that if you simply install Entware, opt will be at the beginning of the path.
Sure, it's "academic" until the moment that the system starts to "misbehave" in some way, or some shell script & add-on no longer function as before, exhibiting some odd behavior, or new error/warning messages begin popping up, so you need to figure out what the root cause of the problem is and then need a solution.
FWIW, my preference is to always avoid, as much as possible, disrupting or interfering with the original, native environment because embedded systems tend to be tightly coupled with the specific functionality/behavior of their own built-in commands. Therefore, when installing Entware, my solution is to give higher precedence to the native built-in commands at the point where the
PATH environment variable is modified.
Now, whenever I want to intentionally call the Entware version of a specific command instead of the built-in version, I have the following options:
1- Inside my own custom shell scripts I can call the command using its full path (e.g. /opt/bin/grep), or I can change the
PATH environment variable locally within the script itself to satisfy its own runtime requirements:
For example:
Bash:
#!/bin/sh
#
PATH="/opt/bin:/opt/sbin:$PATH"
...
2- For interactive shell sessions, I've created custom aliases to call the specific Entware versions:
For example:
Bash:
alias optps='/opt/bin/ps'
alias optwget='/opt/bin/wget'
alias optgrep='/opt/bin/grep'
alias optegrep='/opt/bin/egrep'
...
This way I can either call the built-in commands as usual or run their Entware counterparts via their associated aliases *without* affecting anything else that expects the built-in versions to run without any complications.
IMO, this is the simplest solution, especially for the average user. The alternative would be to start editing every custom script and add-on that no longer behaves "normally" (e.g. new errors/warning msgs showing up), or request their authors to change their code to accommodate the modified Entware PATH environment.
Ultimately, of course, it’s up to each user to decide & choose what the best, simplest solution is for them, their particular preferences & their specific goals for installing Entware.
Just my 2 cents.
Enjoy the Holidays!
I had even reached out to him via PM a few months ago, with no answer. I absolutely love this tool as well, and may end up hosting it myself in order to preserve it... I'll apply the necessary fixes if needed. 
