Playing around with Busybox...

[mikewalsh]

Afternoon, gang.

Not entirely sure this IS the right place for this, but here goes anyway.

My normal 'daily driver' is the 'lite' spin jrb built from Barry's old Quirky64 'April' (v7.0.1). Absolutely rock-solid, and will handle anything I can throw at it.....and for newer browsers'n'stuff, I run a Fossa-based 'chroot'.

I wanted to try out one or two things in the terminal, only to be told they didn't actually exist on the system. I thought they would have been part of Busybox, so I did some checking. This is running Busybox v1.22, dating back around 8 years or so, so I decided to look into 'upgrading' to the current stable build, v1.33.2.

Seems to compile very easily. Coupla questions, though:-

As-is, it's been compiled dynamically. Some of the Q's on the Busybox FAQ seem to suggest that static compilation is preferable. Is it better to be built this way? Is it strictly necessary for Puppy? Barry's Busybox here WAS statically compiled, but then I know Barry has a tendency to do this a lot for his own experiments'n'stuff.

I know 'make install' will automatically add all the necessary links in place. Is there an easy way to remove all the old links, or does this need to be done manually? (*groan*)

Finally, I'll just add this; yes, I know many of the Busybox applets are rather cut-down, basic versions. I think the functionality is probably as much as most folks want, though... I daresay some of you guys will have different opinions, as always!

Any advice/answers would be appreciated, as usual. TIA.

Mike.

[jamesbond]

As-is, it's been compiled dynamically. Some of the Q's on the Busybox FAQ seem to suggest that static compilation is preferable.

It depends on how you plan to use it. Main advantage of static build is that it will run anywhere, including in systems that don't have (compatible) glibc, e.g. in initrd.

Is it better to be built this way?

It depends on what do you plan to use it.

Is it strictly necessary for Puppy?

No, static compilation isn't strictly necessary unless you want to run it in initrd (which I very much doubt you would).

Barry's Busybox here WAS statically compiled, but then I know Barry has a tendency to do this a lot for his own experiments'n'stuff.

Barry builds it statically because he wants busybox to run inside initrd.

I know 'make install' will automatically add all the necessary links in place. Is there an easy way to remove all the old links, or does this need to be done manually? (*groan*)

I haven't used busybox's make install for ages.
It's easy to run an alternative command that will ensure it will install links, including overwriting existing ones:

Code: Select all

busybox --list-full | xargs -I '{}' ln -sfv /bin/busybox /'{}'

But seriously, __BEWARE__ !
Busybox is a critical tool in Puppy, if the new version of Busybox isn't compatible with the old one, you will run into problems; some subtle, some not so subtle. One applet comes to mind "dc". Busybox's old "dc" is different from the its new "dc" and it __will__ break scripts (=your Puppy will become broken).

It's best you __don't__ install the links, instead, call the applet by its name, e.g. if you want to run busybox HTTP's server, then run it as "busybox httpd".

Good luck.

[williams2]

AFAIK busybox's install will create a symlink for each applet
but it will not overwrite a symlink or a file with the same name that is already there.

Code: Select all

mkdir /tmp/aa/
cd /tmp/aa/
cp /bin/busybox .
./busybox --install -s ./
ls -l

lrwxrwxrwx 1   32 Nov  3 15:32  acpid -> /initrd/mnt/tmpfs/tmp/aa/busybox
lrwxrwxrwx 1   32 Nov  3 15:32  addgroup -> /initrd/mnt/tmpfs/tmp/aa/busybox
lrwxrwxrwx 1   32 Nov  3 15:32  adduser -> /initrd/mnt/tmpfs/tmp/aa/busybox

... snip ...

lrwxrwxrwx 1   32 Nov  3 15:32  yes -> /initrd/mnt/tmpfs/tmp/aa/busybox
lrwxrwxrwx 1   32 Nov  3 15:32  zcat -> /initrd/mnt/tmpfs/tmp/aa/busybox
lrwxrwxrwx 1   32 Nov  3 15:32  zcip -> /initrd/mnt/tmpfs/tmp/aa/busybox

[fredx181]

Finally, I'll just add this; yes, I know many of the Busybox applets are rather cut-down, basic versions. I think the functionality is probably as much as most folks want, though... I daresay some of you guys will have different opinions, as always!

Be prepared for unpleasant surprises, specially with older busybox versions, busybox applets can have different options (often less) than the "full" binary (e.g. grep or mount).

[mikewalsh]

Thanks for the replies, guys.

Having compiled it, I wanted to find out if it was worth putting it to use. James & Fred, especially, know about the whole process of integrating it into an OS, so you two are going to be more aware of the pitfalls I might encounter.....

.....which might be more than I realised! Soooo; I think this one's going into the "/dev/null" of what-ifs & maybes.

Cheers.

Mike.

[jamesbond]

C'mon Mike, Neither I nor Fred were discouraging you
We just wanted you to be careful

There is a risk-free approach to it. Build busybox, but don't run "make install" (or run "busybox --install" like williams2 suggested, or my own "xargs" code to install the symlinks). Instead, copy the resulting "busybox" (I think it's called "busybox.unstripped" or something like that) to a place which is __NOT__ in your path (e.g. /mnt/sdc2/test/busybox). You can the invoke and run its applets, for example if you want to run the "dc" applet, use /mnt/sdc1/test/busybox dc. If you like to try its shell, run /mnt/sdc1/test/busybox sh, etc. This way you can still use and play with those newer applets without having to create the symlinks (and risk system-wide breakage).

[fredx181]

C'mon Mike, Neither I nor Fred were discouraging you
We just wanted you to be careful

There is a risk-free approach to it. Build busybox, but don't run "make install" (or run "busybox --install" like williams2 suggested, or my own "xargs" code to install the symlinks). Instead, copy the resulting "busybox" (I think it's called "busybox.unstripped" or something like that) to a place which is __NOT__ in your path (e.g. /mnt/sdc2/test/busybox). You can the invoke and run its applets, for example if you want to run the "dc" applet, use /mnt/sdc1/test/busybox dc. If you like to try its shell, run /mnt/sdc1/test/busybox sh, etc. This way you can still use and play with those newer applets without having to create the symlinks (and risk system-wide breakage).

Yes, always be careful Mike ! (but don't make yourself led by fear )
Busybox is great, e.g. say in some script I need to run "strings", mmm.. don't have 'strings' installed, but wait... there's busybox applet "strings" so then I make it just; busybox strings ....

[mikewalsh]

@jamesbond / @fredx181 :-

Oh, there's no 'fear' involved.....just a healthy dose of caution, since I've got Quirky exactly how I want it, and do NOT wish to mess it up!

I do have a "test copy" of Quirky set up, however; been using it to trial new kernels/new variants of the glibc/various other things I get interested in. Good idea; I'll transplant it into Quirky-test - the way you suggest - and do some experimenting.

I admit, I wasn't aware you could call it in that fashion. I understood it needed to be via the 'linked' commands, but if it'll work like that, perhaps I can experiment with my latest idea after all. The "script" command is required; Quirky's 8-year old original doesn't have it, but the current 'stable' release does.

Of course, it's that much easier for us in Puppyland to run experimental 'cloned' copies in this fashion than just about any other distro in existence..!

Ta for the advice, guys. Maybe this'll work out after all.....and if I'm happy with it, I can transplant it back into the "daily-driver", and use it in the same fashion. Sounds like it could be even more versatile than I at first thought.

Cheers!

Mike.