I frequently compile and run the default config of the latest Busybox - but only at a user-level. Porteus' devel module makes that super easy to compile.
So no problem as a user (putting busybox and it's symbolic links in a directory in front of my path - the usual stuff.)
BUT, I'd like to take it further to see if I can start replacing things on a system-wide level without breaking things too much.
So I'm wondering what would you suggest as a system plan for a busybox test? Replacing the gnu file utils one by one and seeing what breaks, or perhaps making an entire module to load first?
I kind of have the itch to see if I can make a "busybox'ed" version of Porteus, but as you can see, I'm more likely to break it and end in tears. As a user-level thing, no sweat. But wholesale replacement? I'm scared....
Seeking busybox guidance
Seeking busybox guidance
That's a UNIX book - cool. -Garth
- ncmprhnsbl
- DEV Team
- Posts: 3924
- Joined: 20 Mar 2012, 03:42
- Distribution: v5.0-64bit
- Location: australia
- Contact:
Seeking busybox guidance
yes ... either way.. the first is probably more sensible, creating a renamed/backup of the target binary before symlinking to busybox..
and with the module approach i would activate it after boot, since the most likely problem would occur in the rc scripts ..ie some function/option lacking in the busybox applet(can't really think off the top of my head what, though)
and then you should be able to just deactivate if there's a problem.. unless the activate/deactivate script is somehow broken by it...
from memory, i think Brokenman mostly just preferred the greater functionality of the standard gnu utils..
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44
Seeking busybox guidance
Thanks for the tips. I think I'll leave busybox-init for the last. I'll be saving my state often.
Just a personal project - not trying to change Porteus' overall direction.
I normally build the whole binary, and not individual apps, but that can be done if one wanted.
For lurkers, just to show my ignorance, I love busybox vi - I don't need vim or some other module. So I like to keep on top of the latest bug-fixes with the latest stable source.
It's all there... mostly guided by the faq
https://busybox.net/FAQ.html#getting_started
After grabbing the busybox source, all I do is this:
Then I'll toss the new busybox binary into the start of my path say at /usr/local/bin
Then I create a symlink in that directory to call it as vi. However, since a slightly older busybox vi exists on the system, I'll rename the symlink to make sure I'm using the NEW vi, (renamed / linked as bvi) not the original. Two steps to that however.
Makes the correct symlink. BUT once that has been created, I'll manually rename that symlink itself afterwards to my desired name, bvi.
So now when I want to use vi, I'll invoke it as bvi just to keep the old and the new straight. Or as in the faq, do a for-loop and have it create all the symlinks for everything for you....
One *could* build an individual applet just for vi alone, but I slack it with the bloated (1mb!) binary in case I want to call up something else that may not be in the canonical gnu-utils stuff.
How to test if you've done it right? BB can be very customized with a menuconfig. The original vi has no help. But if you've done a defconfig, you can test by seeing help:
Or in my case with the rename, bvi --help
It's all Porteus' fault for teasing me when I first recognized the built-in vi editor!
Just a personal project - not trying to change Porteus' overall direction.
I normally build the whole binary, and not individual apps, but that can be done if one wanted.
For lurkers, just to show my ignorance, I love busybox vi - I don't need vim or some other module. So I like to keep on top of the latest bug-fixes with the latest stable source.
It's all there... mostly guided by the faq
https://busybox.net/FAQ.html#getting_started
After grabbing the busybox source, all I do is this:
Code: Select all
make defconfig
make
Then I create a symlink in that directory to call it as vi. However, since a slightly older busybox vi exists on the system, I'll rename the symlink to make sure I'm using the NEW vi, (renamed / linked as bvi) not the original. Two steps to that however.
Code: Select all
ln -s busybox vi
Code: Select all
mv vi bvi
One *could* build an individual applet just for vi alone, but I slack it with the bloated (1mb!) binary in case I want to call up something else that may not be in the canonical gnu-utils stuff.
How to test if you've done it right? BB can be very customized with a menuconfig. The original vi has no help. But if you've done a defconfig, you can test by seeing help:
Code: Select all
vi --help
It's all Porteus' fault for teasing me when I first recognized the built-in vi editor!
That's a UNIX book - cool. -Garth
- Rava
- Contributor
- Posts: 5401
- Joined: 11 Jan 2011, 02:46
- Distribution: XFCE 5.01 x86_64 + 4.0 i586
- Location: Forests of Germany
Seeking busybox guidance
That's true, you can check that out when something at boot goes wrong and you are in the busybox shell trying to look for the reasons. (You can force that by creating a wrong entry in your porteus.cfg if you want)ncmprhnsbl wrote: ↑07 Nov 2021, 19:38i think Brokenman mostly just preferred the greater functionality of the standard gnu utils..
Often I then realize that common used parameters are no longer valid since I not run the actual program but the busybox replacement instead. Since I only run that in very rare occasions I cannot recall any details, but its still reality that many parameters are missing from the busybox replacement commands.
And that can be a reason for a broken system or broken scripts that rely one some of these now missing parameters.
Cheers!
Yours Rava
Yours Rava