[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issues with exported functions

From: Eduardo A . Bustamante López
Subject: Re: Issues with exported functions
Date: Thu, 25 Sep 2014 13:45:47 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

> Not quite.  While autoloaded functions are lazily evaluated, you have to
> pay the price of searching $FPATH and loading them in every shell, and
> there still has to be a mechanism to indicate which functions should be
> autoloaded in each shell.
How about lazy loading functions using the following mechanism:

# code
foo arg1 arg2 arg3

1) Search for an alias called 'foo'
2) Search for a function named 'foo'
3) Search for a variable named 'foo' with '(){ ...; }' as contents
4) Search for a builtin ...

So far, this is compatible with what we already have, right?

Now, this method (of skipping the function definition until we
attempt to use it) could allow for a special shopt, which disables
the step '3'.

Something like: shopt -s nofunexp, which changes step 3 to

  3) Search for a variable named 'foo' with '(){ ...; }' as contents
  IF nofunexp is disabled.

So, I can now put: shopt -s nofunexp in my scripts proactively, to
avoid function exports at all.

Also, a special array variable could be introduced, like:

BASH_ALLOWED_FUNEXP=(foo bar baz), which acts as a whitelist to allow
only a certain set of functions to be taken from the environment.

So, this way, we keep backwards compatibility, but we also have the
opportunity to disallow exported functions.

Eduardo Bustamante

reply via email to

[Prev in Thread] Current Thread [Next in Thread]