mjhjmtu

In the title, I use the expression "overriding wrapper" to refer to a function foo that overrides some original function falls, and calls this original function (or a copy of its) during its execution.

I have found Stack Exchange threads about this (like this one), but in my case I have the additional requirement that both the original foo as well as the overriding foo are meant to be accessible through FPATH, and autoloaded. (The overriding version presumably would appear earlier in the search sequence, thus shadowing the original version.)

Is there a way to do this?

FWIW, in the particular scenario I'm dealing with, the overriding foo just assigns some none-standard values to some global variables that the original refers to for doing its thing.

You can use this function to load the code of a function from a file in the same way that autoload does it, without the restriction that the file name has to match the function name.

## load_from FILE FUNCTION_NAME
load_from () 
 eval "$2 () $(<$1) "

Here's how the wrapper code looks like. $^fpath/somefunction(N) expands to the list of definitions of somefunction in the load path ($^fpath/somefunction expands to the list of /dir/somefunction for each /dir in $fpath, and the glob qualifier (N) restricts the expansion to existing files). Note that this only works if you have a single level of wrapper and the wrapper is in the fpath.

#autoload somefunction
local some_parameter=overridden_value
local autoload_files
autoload_files=($^fpath/somefunction(N))
load_from $autoload_files[2] somefunction_wrapped
somefunction_wrapped "$@"

For replacing binaries/init.d files/scripts with a wrapper in Debian, I have used in production for years, with great success, file diversions.

If you just drop by a wrapper with the same name as the original file you want to shadow, what it happens is in the next update of the corresponding package the wrapper will be most probably rewritten by the file you intend to replace.

So for instance, for adding a wrapper for gcc, you would do:

sudo dpkg-divert --add --rename --divert /usr/bin/gcc.real /usr/bin/gcc

After that, you can place your wrapper at /usr/bin/gcc.

From then on, the old gcc binary will be /usr/bin/gcc.real, and most importantly, all the subsequent gcc future updates done/installed by Debian APT system, will install new instances of /usr/bin/gcc as /usr/bin/gcc.real and will leave your wrapper undisturbed.

See Replacing binaries with dpkg-divert

From man dpkg-divert

dpkg-divert is the utility used to set up and update the list of
diversions.

File diversions are a way of forcing dpkg(1) not to install a file
into its location, but to a diverted location. Diversions can be used
through the Debian package scripts to move a file away when it causes
a conflict. System administrators can also use it to override some
package's configuration file, or whenever some files (which aren't
marked as “conffiles”) need to be preserved by dpkg, when installing a
newer version of a package which contains those files.

PS I used this technique for adding extra options to the BIND and ISC-DHCP init scripts.