OK, some "theory of programming 101" seems to be in order:

Subroutines in general come in two forms: procedures and functions. PASCAL had this difference laid down in keywords, while C and all its children blurred this fact by only having functions.

The difference is: functions have one (exactly one!) return value, procedures have none. So one could treat procedures as special functions with a return value of <void> (this in fact is what C does).

In "normal" programming languages the return value of a function could be anything: a number, a string or any other data type the language is capable of to define. For instance:

Code:

mylog=calc_natural_log( 5 )

Will pass the number (constant) 5 as argument to the function "calc_natural_log" and the function will return something (perhaps a floating point number), which in turn gets stored in the variable "mylog".

In shell programming function can only have one sort of return values: an unsigned short short integer, equivalent to the "return code" (or "error level") the OS knows. In fact this is (treated as) the same as this shows:

Code:

if myfunc "arg1" "arg2" ; then
     echo "myfunc() returned 0"
else
     echo "myfunc() returned non-zero"
fi

The if-keyword treats the return code of the function the same way it would treat the RC of any external command:

Code:

if /some/command ; then
     echo "command returned 0"
else
     echo "command returned non-zero"
fi

That leaves the question: how to manipulate data across functions/procedures? First we need to differentiate between data the function only needs to know and data the function needs to change.

Data the function needs to know can be set as globals. It is good practice to use - as a rule of thumb - globals only for constants. You can manipulate such constants via the dot-execution method, but in most cases this is a bad idea because it indeed introduces a side effect of the execution of the function.

In general it is a good idea to pass all the information a function needs to know as a parameter to it. I do usually create a "function outline" before i even write it by simply asking what the function needs to know (the parameter set) and what it needs to give back. This way, when i start actually writing the function, i already have the "interface" of what it has to look like to the outside ready.

Here is an example: i once wrote a function for distributed execution of commands (via ssh-sessions). Now i thought: what do i need to know?

1) the host on which to execute
2) the command to execute
3) the use which to use for the connection
4) the user under which to execute

What do i need to give back to the calling routine?

1) The error level of the command executed
2) any output it might produce (stdout and stderr)
3) a return value of the function itself in case something goes wrong (host refused connection, etc.)

So i could write a function outline like that:

Code:

function fExecRemote
typeset chHost="$1"
typeset chConnUser="$2"
typeset chRemUser"$3"
typeset chCommand="$4"

ssh -nqo 'BatchMode = yes' "$chConnUser"@"$chHost" "sudo su - $chRemUser $chCommand"

return $?
}

# main()

fExecRemote "host1" "myself" "myself" "ls -l"
echo $?

exit 0

Things to do (obviously): catch the output, check if a connection is possible (system can be pinged, ssh-keys are exchanged, ...) and so on ... but this is implementation, not design.

For things a function has to manipulate (instead of just know) there are two ways: first, you can catch the <stdout> of a function:

Code:

function fSub
{

echo "bla"
echo "foo"
echo "bar"

return 0
}

# main()
typeset OUTPUT=""

fSub | while read OUTPUT ; do
  ....
done

Second, there is the process substitution:

Code:

function fSub
{
echo "bla"

return 0
}

# main()
typeset var=$(fSub)

I hope this helps.

bakunin