POSIX compliant way to see if a function is defined in an sh script

Question

I'm after THE proper way to see if a function is defined or not. A POSIX compliant way.

__function_defined() {
    FUNC_NAME=$1
    d=$(declare -f $FUNCNAME)

    if [ "${DISTRO_NAME_L}" = "centos" ]; then
        if typeset -f $FUNC_NAME &>/dev/null ; then
            echo " * INFO: Found function $FUNC_NAME"
            return 0
        fi

    # Try POSIXLY_CORRECT or not
    elif test -n "${POSIXLY_CORRECT+yes}"; then
        if typeset -f ${FUNC_NAME} >/dev/null 2>&1 ; then
            echo " * INFO: Found function $FUNC_NAME"
            return 0
        fi
    else
        # Arch linux seems to fall here
        if $( type ${FUNC_NAME}  >/dev/null 2>&1 ) ; then
            echo " * INFO: Found function $FUNC_NAME"
            return 0
        fi
    echo " * INFO: $FUNC_NAME not found...."
    return 1
}

All of the above are considered bash'isms according to debian's checkbashisms script.

Trying to grep the script is also not ok. for example:

    if [ "$(grep $FUNC_NAME $(dirname $0)/$(basename $0))x" != "x" ]; then
        # This is really ugly and counter producing but it was, so far, the
        # only way we could have a POSIX compliant method to find if a function
        # is defined within this script.
        echo " * INFO: Found function $FUNC_NAME"
        return 0
    fi

won't work because the script is also supposed to work like:

wget --no-check-certificate -O - http://URL_TO_SCRIPT | sudo sh

So, what's the proper, POSIX compliant way to do this?

Plain sh please, no bash, no ksh, no other shell, just plain sh. Oh, and without actually trying to run the function too :)

Is it possible?

I have found a POSIX compliant solution:

if [ "$(command -v $FUNC_NAME)x" != "x" ]; then
    echo " * INFO: Found function $FUNC_NAME"
    return 0
fi

The question now, Is there a better solution?

Answer 1

I have found a POSIX compliant way

if [ "$(command -v $FUNC_NAME)x" != "x" ]; then
    echo " * INFO: Found function $FUNC_NAME"
    return 0
fi

The question now, Is there a better solution?

Answer 2

This answer isn't POSIX so won't compete with the accepted answer, however can be a FWIW/TDIL for when you just need something for specific shells.

In zsh you can do test "$(whence -w name)" = 'name: function'.

In bash you can do test "$(type -t name)" = 'function'.

Extra details for bash:

function fn () {
  echo 'my function'
}

if test "$(type -t fn)" = 'function'; then
  echo 'fn is a function'
else
  echo 'fn is not a function'
fi

if test "$(type -t missing-fn)" = 'function'; then
  echo 'missing-fn is a function'
else
  echo 'missing-fn is not a function'
fi

You can learn more about bash bultins by typing help in your prompt, then help type and help test.

type -t name can also tell whether name is all sorts of things, including a builtin, a file, or as demonstrated a function.

If you only care that a variable or function exists, you can use:

if test -v name; then
  echo "name is present: $name"
else
  echo "name is missing"
fi

Answer 3

The following is POSIX compliant should work possibly everywhere:

checkfunc() {
   case "$(type "$1" 2>/dev/null | head -n1)" in
   *" function"|*" function from zsh") return 0; ;;
   esac
   return 1
}
# Tested with:
# My shell is bash
script="$(declare -f checkfunc)"'
if checkfunc checkfunc; then :; else echo $0:error:not function; exit 1; fi
if checkfunc ls; then echo $0:error:executable; exit 1; fi
if checkfunc type; then echo $0:error:builtin; exit 1; fi
if checkfunc does-not-exists; then echo $0:error:not-exists; exit 1; fi
'
docker run --rm bash bash -c "$script"
docker run --rm alpine ash -c "$script"
docker run --rm ubuntu dash -c "$script"
docker run --rm alpine ash -c 'apk add mksh >/dev/null && mksh -c "$1"' - "$script"
docker run --rm alpine ash -c 'apk add zsh >/dev/null && zsh -c "$1"' - "$script"

If I could say, I would say that I also could have sources of SVR4 and patched ksh so it's compilable with current GCC and tested it there too and type could just output <xxx> is a function there, just like ash.

zsh happens to output <func> is a shell function from zsh, so I decided to handle the from zsh specially.

Answer 4

While I can understand why you might think so, dynamically pulling your script from another location is no great barrier to parsing (or "grepping") it as you like before you run it. Such a thing can be accomplished in several ways, but, as far as I can make out, they will all require a basic file descriptor for functionally complete operation.

Bash and its ilk provide us the convenience of transparent file descriptors via redirected sub-shelled commands which allow for all kinds of pipeline flexibility like this:

eval "$(wget --no-check-certificate -O - ${_URL} | tee \
    >(read func; echo '_FUNC='"$(grep -Eo '^[^ |^#]*()' <(echo "${func}"))") \
    | sudo sh)" 

But, as has been mentioned already, such syntax devices are not specified by POSIX, and so you must find another way. Also, shorter though it may be, that can be a little confusing. Probably there are much better ways to do that, but I imagine them requiring 2 or 3 subshell levels at least. (It sure would be cool to be shown otherwise, though.)

What POSIX does specify, however, is the very useful heredoc. The heredoc is rare among declarable POSIX variable syntax types not only because it can neatly span multiple lines without escape kludges, or because it allows for clean definition of shell substitution by simply quoting its terminator, but most importantly because it describes a file type handle. This quality of the heredoc is often overlooked, perhaps because Bash and co have largely obviated its importance for some time now, but we should be reminded of it every time we adhere to the convention of terminating a heredoc with the "end of file" acronym EOF.

In order to pull in a script file, modify it programmatically, and then execute it with a shell interpreter you will need a file descriptor. You can read and write to /tmp/ to allow for this, of course, but I generally try to avoid that because it just feels sloppy. You could even, perhaps, rewrite yourself if you must, but it is probably not the best habit to get into. If you find real cause to do this, however, the safest way is probably to define the rewrite code in a function at the beginning of your script and only call it at the very end so you can be sure the entire file has been fully loaded into memory. Something like this:

_rewrite_me() {printf %s "${1}" > ${0} && exec ${0}} 
#SHELL CODE
#MORE 
_NEW_ME="$(printf %s "${_MORE_SHELL_CODE}" | cat <${0})"
rewrite_me ${_NEW_ME}

Still, I like the heredoc best, and I think it is the missing puzzle piece in this case. The following is made short and simple with use of the heredoc, should be fully POSIX compliant, and should easily be adapted to your purposes, I hope:

#!/bin/sh
_URL='http://URL/TO/SCRIPT'

_SCRIPT="$(wget --no-check-certificate -O - ${_URL} |\
    grep -Ev '^#!')" 

_FUNC="$(sed -n 's:^\([^ |^#|^=]*\)().*{.*$:\1:p' <<_EOF_)"
${_SCRIPT}
_EOF_
echo "${_FUNC}"

sh <<_EOF_
${_SCRIPT}
_EOF_