ok... this might require a little more explanation as to why I'm asking this at all. I'm specifically looking for a solution for the Kindle Touch here, but this is a general question mostly independent from the actual device.

Some of the already existing hacks require patches to (existing) Java classes. The ones I know about are:

GUI Launcher by Yifan Lu

Localization (more specifically, the locale_enabler stuff)

Font Hack (more specifically, the "Kindlet Jailbreak")

There are generally two ways to achieve such a replacement. The obvious one is to simply modify the existing jar. The less obvious, but more elegant and preferred one (at least in this context) is to put them in a different jar, making sure that it appears before the original jar in the classpath. This works because when a class is initially looked up, the classpath is scanned "linearly", and the first occurrence wins.

The second alternative is preferred in this context because it entirely avoids messing with Amazons proprietary files. It will (generally) not affect framework updates, it can be easily undone, etc.

For the first two of the abovementioned hacks, the second method worked, because the classes that required changes were inside /opt/amazon/ebook/booklet/. The "patches" went into /opt/amazon/ebook/lib/ instead, and thus were always loaded before the originals (see below).

For the third hack, it didn't work. But for this particular case (the affected jar is the "simple_json" one), this isn't too much of a problem either, because simple_json is released under the Apache Software license, so it can be freely distributed in the hack installer and uninstaller.

However now, I'm running into a problem. The reason is that in order to solve this problem/request, a class inside /opt/amazon/ebook/lib/ReaderSDK-impl.jar has to be changed. Publically distributing this file in an installer/uninstaller is extremely questionable from a legal point of view. And of course, I want to use the "elegant" way.

So after all this introduction, here are some relevant lines from /etc/upstart/framework (a lot of the file is stripped away here):

The "problem" here is the order of the classpath, or more specifically, the output of "find". Any file in $EHOME/lib is guaranteed to appear before the files in $EHOME/booklet, but the order of files inside the same directory is essentially random.

A simple approach would of course be to edit the file directly, inserting a few sort commands. But that would again go against my goal of being as unintrusive as possible by only *adding* stuff (which can be easily removed) instead of *modifying* stuff.

One way that I thought of, and that would probably work, is to create the file /usr/local/bin/find, which would act as a wrapper to /usr/bin/find, taking some further action on particular arguments.

The "problem" here is the order of the classpath, or more specifically, the output of "find". Any file in $EHOME/lib is guaranteed to appear before the files in $EHOME/booklet, but the order of files inside the same directory is essentially random.

Can't you simply put the added file in a sub-directory inside $EHOME/lib lets say $EHOME/lib/myLib and then put its path before the parent path?!

Unfortunately, my idea of using /usr/local/bin/find didn't work (I tried it, but it seems like the built-in busybox commands are preferred over $PATH), and neither did cscat's proposal

So... any other ideas?

I had that problem with busybox. I was not able to use a fully-qualified path, so I launched my app inside a new shell (different busybox) that did not have the command that I needed built-in, so it used the one on the search path.

For example, when booted to main, to start a shell using the diags busybox, do:

mount /dev/mmcblk0p2 /mnt/mmc
/mnt/mmc/bin/busybox sh

Of course, that was only useful on the K4, which has very different Busyboxes on main and diags, but on the touch they were identical, when I checked. But don't let that stop you. You can use a custom busybox.

The new shell inherits your PATH, but if you now use a command that is not in the diags busybox but which is in and would be intercepted by main busybox, you are good to go, and the command on the search path now runs instead of the stripped busybox version that is missing options you need...

Anyway, that is how *I* solved a problem similar to the one you described... *

Of course, you probably want to start a shell in a DIFFERENT busybox that is in /mnt/us/bin, right?

SUMMARY: To break out of the Busybox "sandbox" for its built-in commands, start a child shell from a different Busybox that does not have your chosen command built-in, or at least has a more-capable built-in that does what you need.

P.S. Busybox commands do not need symlinks. You can just stick "busybox" in front of busybox built-in commands (like "busybox sh").

Got that. But at the point in time where I need it, there hasn't even been a chance to tamper with these things... (AFAIK)

The problem is that I'm trying to influence (if at all possible) the "environment" that the KT sees while executing /etc/upstart/framework, while it is booting. I had hoped that the "find" command there would be "substitutable" because of $PATH resolution, but it's obviously using the built-in one from busybox at that time.

So the question is pretty much: can anybody find a "hook point" in that script where one could influence how the individual commands are resolved? I was also thinking about aliases which could be (transitively?) introduced through /etc/upstart/(functions|env), but I doubt that at this time of the startup process, any of these would be used, since most of the commands are "busybox" anyway...

P.S. Busybox commands do not need symlinks. You can just stick "busybox" in front of busybox built-in commands (like "busybox sh").

There are two ways that busybox may be configured -
One (which does not require sym-links) does require that /proc be mounted.

The other configuration choice does require links (either symbolic or hard) but will work without /proc mounted.
This configuration option also allows you to just replace a bb link with an executable and you will get the real-executable. Also a real-executable "wins" according to the usual path rules over the bb link.

From your post, the BBs that you write about must be configured per the first choice above.
I always option my builds of BB according to the second way.

But I just wanted to add that it is possible to bypass this busybox configuration option's shortcoming (as demonstrated in the building a better busybox thread).

Assuming you have a spare busybox lying around... if one aliases the find command find to busybox find the second -replacement - busybox is invoked - something similar could perhaps work for this. IE an aliasing solution. As outlined by GM above. Don't see why this could not be further abused.

Just thinking out loud. Simply wanted to say that this hard-coded command line limitation can seemingly be bypassed. I also noted that it could be further bypassed by added the <ENV=whatever> environment variable in non interactive shells FWIW.

Oh and in other news I finally got my cvm to spit out the bits I was looking for...
(and my logs configured in a sane enough way to read it easily)