Quote:
Originally Posted by twobob
hmm, this is true but JUST MAYBE I can convince it otherwise with some aliases, it's worth a pop. I'll give it a go now.
|
Twelve hours too late (you already know that this works) but with a few hours sleep, I can say why it works.
Alias expansion happens before the search for the command.
It has to, once some sleep and thought is applied to the question.
The "typical" use of alias commands is to append options to the command that over-ride the usual defaults.
Here, the alias commands are used to prepend the multi-call binary's name.
Regardless of how Busybox is configured, it never has itself as its own built-in, so the normal "path search" system is used to find the executable.
So with the 1.20 version being found by name from the "path search", it gets called even from within the 1.7 command line shell.
This alias usage should work with **any** shell that supports the alias expansion feature, not just ash and bash.
One question pops into my mind about this:
Does the alias list (which looks like environment settings) get passed to child shells the same as the other environment settings?
No need to test for that, it should be obvious with just normal use - something will mis-behave.
One maintenance item pops into my mind:
When the full sized utility is installed (which would normally replace the busybox sym-link), the installation process will have to sed or awk the .alias list and unset the alias entry.
For instance:
The new busybox (and alias list for the old busybox) provides swapon / swapoff - -
If those are built from the full sources and installed, the swapon=busybox swapon has to come out of the list and be unset from the environment before they can be accessed from the command line.
But overall, a slick way of dealing with an executable that normally depends on sym-links (or hard-links) when it is installed on a file-system that does not support either.
Nice job.