On Sat, Feb 09, 2008 at 12:36:53PM +0000, William Pursell wrote: > phillinux wrote: >> >> I'm trying to write a bash shell script to create user accounts that >> calls 2 functions. I can't call these functions from the script or the >> command line. The set command seems to show the loaded script in the >> shell (loaded with . FunctionName at command line) with other >> environmental variables. ALSO: The type command does not recognize the >> function. >> >> The script and functions work on my laptop running Fedora (with one >> small glitch). Is there something I can do to my Debian server to get >> functions recognized?? > > From some other comments in the thread, it sounds like you are trying > to do something like the following: > >> $ cat foo >> >> g() >> { >> printf 'in g\n' >> } >> $ cat bar >> #!/bin/sh >> >> g >> $ . foo >> $ ./bar # won't work since bar doesn't source foo >> ./bar: line 3: g: command not found > ... > If you source the file with the function definitions, it makes > the functions available in the current shell, but not in subshells > that you may invoke.
A qick perusal of bash(1) shows that functions can be exported to subshells, e.g.: $ . foo $ ./bar ./bar: line 2: g: command not found $ export -f g $ ./bar in g I suppose that could be (mis)used to implement some form of polymorphism in shell scripts; the script executes g, but has no control over what g actually is. Could be useful/confusing/dangerous... I guess the same applies to sourcing function definitions from within a script, since the function is still external to the script, though it's at least defined in a file. Ken -- Ken Irving, [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]