ltmain.in - why no shell functions?

[John Reiser]

ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18)
-----libtool.info-4:
   Then in `ltmain.in' ...  This is the real code... I wish I could
condense it a little more, but I don't think I can without function
calls.
-----

Why not use shell functions?  If there are environments that are so
primitive that they do not have shell functions, then those environments
should be enumerated, so that when their use becomes low enough, then
support for them can be eliminated, and the vast majority of projects
(counting by developers, installers, or machines) can enjoy the 
benefits of shell procedures.  And 'bash' is getting good enough
that one could say, "Use bash."  Even today, the fraction of systems
with "good enough" implementations of shell functions is large enough
that a configuration-time choice to use them in ltmain.sh has strong
appeal.  Similarly, if there are implementations of shell procedures
that have bugs or misfeatures, then those implementations and their
deficiencies should be enumerated.
Besides providing some incentive for upgrades by their proprietors,
it may well be that some features of shell procedures can be used
in all implementations already.

In ltmain.in, a proper definition of 'show' requires the use of shell
functions to handle the syntax vagaries of redirecting stdout to
stderr without further complicating the quoting:
        function show() {
          echo "$@"  1>&2
        }
The several hundred lines of logic to translate *.la into the right
filenames and the correct setting of $shlibpath_var are needed in
more than one place: not only when --mode=link , but also for
some cases of --mode=execute , and the forgotten case of running
/bin/ldd .
The "programming gymnastics" of '%%%MAGIC variable%%%', or of TAG
configurations, can be simplified and shortened dramatically by
using shell functions.

So, what are the problems and the specific systems that require
avoiding shell functions?

-- 
John Reiser, address@hidden