Botstrapping and cross-compiling

Maybe it’s me, but I like to know the environment I work in and add facilities to make my daily workflows easier. I have more than 50 executables (mostly shell script) under ~/bin, some are used daily, others once or twice a year. The main advantage is that for both cases, shell scripts provide very good documentation of how I accomplish specific tasks.

This is one of the main reasons for using a computer: automating tasks and reducing repetitive work. If not, I tend to prefer human interaction, as generally, human beings tend to be friendlier than robots.

So when I get a new device, a new environment, or when I have to work from a different workstation, one of the first things I do is to look around and see what’s available and eventually add those little programs I find so useful.

I even have a USB stick with appimages and scripts for GNU/Linux and portable applications for Windows.

In some environments, some policies do not allow installing new programs, downloading executables, or using USB drives.

Fortunately, both Windows and POSIX-based systems have shells, and I am still allowed to open a text editor and save textual files.

While the language given by the shell is not always ideal, it is possible to write many utilities with it. If lucky, it is possible to let do the hard work to external programs and just glue them together.

This is coincidentally part of the Unix philosophy; which provides little specialized tools that can be put together easily.

Normally one should take advantage of programs available on the systems, most scripts just call some programs and glue them together. Of course, being able to install third-party programs makes everything easier, why reinvent the wheel if there is not enough time?

But this year I had to work in a (for me) new environment. A Linux distribution, missing most of the coreutils executables (not even cut and sort where available!), and with no package manager.

The /bin directory is painfully empty. Only the absolute minimum is available: an old busybox and half a dozen executables.

Also, the available programs (like kill and chmod), are crippled, missing many options, and of course, other useful programs, like grep or awk, were missing completely.

Oh, and because there is only a minimal sh shell, there is no autocompletion and no history.

While it might seem like a very improbable scenario to encounter such a device, nearly everyone has one with approximately the same limitations: android phones.

It is possible to enable access to the shell, but it is a very stripped-down environment. If you can install programs, termux provides a package manager and nearly all programs one can expect on a GNU/Linux distribution. Unless you have an older phone, as termux does not support versions previous to Android 7.

Maybe it’s just me, but the idea of working in such an environment is horrible.

The only possibility to work efficiently, without changing the environment, is by offloading as much work as possible on a separate PC. But as tools like ssh are missing too, even copying a file is a process difficult to automate (and of course tar and other archiving utilities are missing).

So either I could do everything by hand, or try to offload as much as possible.

I know from experience that by doing everything by hand I will do the most improbable and dumbest errors, and burn a lot of time and energy solving non-issues multiple times. I tried offloading as much work as possible, but just synchronizing content and trying to debug the issue is such a hurdle that I decided I had to come up with something else.

Bootstrapping my toolbox on that machine.

The downside is that it will take some time to get something useful.

The upside is that I do need to do it only once.

If I do everything by hand, I will need more time for every task. And every time, if something goes wrong, there will be doubt if I had done something differently.