schumaku wrote:Just a note: In general, it might be nice to get "stanards" compliant commands in place. However, this can inerfer with an kind of QNAP Firmware supplied scripts and Web CGI program - as thier code is drawn to the utilities as availbakle by default....
The reality of your observation is quite bothersome.
There is no excuse for this! As NAS units typically have lots of storage available, I'm still trying to understand why "BusyBox" is being used in the first place. BusyBox makes sense on devices like Routers that have limited Flash space as their only storage, but on a NAS it is a terrible thing to install.
I note that IMPORTANT Notes!
section of the QNAP Wiki article: Running Your Own Application at Startup
Note#2 provides the advice: "Always use the full system path because locations like /opt/bin or /opt/sbin might not have been exported yet when the Autorun.sh is executed
If QNAP's scripts insist on using the limited "BusyBox" apps (symlinks to Busybox), they should be calling the them as "busybox <command>" rather than "<command>", OR
they should be defining the PATH variable at the beginning of their scripts, to ensure the correct command is run OR
they should be using the full system path when calling commands.
I guess I'll have to check whether I'm in a "interactive" session, before I redefine the PATH variable in my .profile/.bashrc files. In your "opinion" (ie I won't hold you to it), do you think this will be sufficient to allow "non-interactive" sessions like QNAP scripts to function properly. (I thank you for sharing this unpopular reality, at least now I know to look for this when I discover issues).
In most cases the Optware commands will be a superset of the busybox ones, however I know this is not always true.
This is horrifying. Totally horrifying. There is simply no excuse for using "Busybox" in the first place.
This is irresponsible programming. I am being constantly biten by the limitations of busybox, and am constantly using Optware replacements to solve these problems.