|
Size: 2602
Comment:
|
Size: 3219
Comment: Redirecting prompts to stderr allows clean return values to be captured
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
| Line 8: | Line 9: |
| . | |
| Line 14: | Line 16: |
| }}} The drawback of this method is that the function is executed in a SubShell, which means that any variable assignments, etc. performed in the function will not take effect in the caller's environment. This may or may not be a problem, depending on the needs of your program and your function. Another drawback is that everything that should be printed by the function foo() is captured caught and put into the variable instead. This leads to problems if foo() also writes things that are not the returned value. |
}}} One drawback of this method is that the function is executed in a SubShell, which means that any variable assignments, etc. performed in the function will not take effect in the caller's environment (and incurs a speed penalty as well, due to a `fork()`). This may or may not be a problem, depending on the needs of your program and your function. Another drawback is that ''everything'' printed by the function `foo` is captured and put into the variable instead. This leads to problems if `foo` also writes things that are not intended to be a returned value. To isolate user prompts and/or error messages from "returned" data, redirect them to stderr which will not be captured by the caller. . {{{ foo() { echo "running foo()..." >&2 # send user prompts and error messages to stderr echo "this is my data" # variable will be assigned this value below } x=$(foo) # prints: running foo()... echo "foo returned '$x'" # prints: foo returned 'this is my data' }}} |
| Line 18: | Line 34: |
| . | |
| Line 24: | Line 41: |
| }}} The drawback of this method is that, if the function ''is'' executed in a subshell, then the assignment to a global variable inside the function will ''not'' be seen by the caller. This means you would not be able to use the function in a pipeline, for example. |
}}} The drawback of this method is that if the function ''is'' executed in a subshell, then the assignment to a global variable inside the function will ''not'' be seen by the caller. This means you would not be able to use the function in a pipeline, for example. |
| Line 28: | Line 48: |
| . | |
| Line 37: | Line 58: |
| # In the event that this were a real program, there # would have been error checking, and a trap. }}} The drawbacks of this method should be obvious: you need to manage a temporary file, which is always inconvenient; there must be a writable directory somewhere, and sufficient space to hold the data therein; etc. On the positive side, it will work regardless of whether your function is executed in a subshell. For more information about handling temporary files within a shell script, see [[BashFAQ/062|FAQ 62]]. |
# If this were a real program, there would have been error checking, and a trap. }}} . The drawbacks of this method should be obvious: you need to manage a temporary file, which is always inconvenient; there must be a writable directory somewhere, and sufficient space to hold the data therein; etc. On the positive side, it will work regardless of whether your function is executed in a subshell. For more information about handling temporary files within a shell script, see [[BashFAQ/062|FAQ 62]]. For traps, see SignalTrap. ---- CategoryShell |
How do I return a string (or large number, or negative number) from a function? "return" only lets me give a number from 0 to 255.
Functions in Bash (as well as all the other Bourne-family shells) work like commands: that is, they only "return" an exit status, which is an integer from 0 to 255 inclusive. This is intended to be used only for signaling errors, not for returning the results of computations, or other data.
If you need to send back arbitrary data from a function to its caller, there are at least three methods by which this can be achieved:
- You may have your function write the data to stdout, and then have the caller capture stdout.
foo() { echo "this is my data" } x=$(foo) echo "foo returned '$x'"
One drawback of this method is that the function is executed in a SubShell, which means that any variable assignments, etc. performed in the function will not take effect in the caller's environment (and incurs a speed penalty as well, due to a fork()). This may or may not be a problem, depending on the needs of your program and your function. Another drawback is that everything printed by the function foo is captured and put into the variable instead. This leads to problems if foo also writes things that are not intended to be a returned value. To isolate user prompts and/or error messages from "returned" data, redirect them to stderr which will not be captured by the caller.
foo() { echo "running foo()..." >&2 # send user prompts and error messages to stderr echo "this is my data" # variable will be assigned this value below } x=$(foo) # prints: running foo()... echo "foo returned '$x'" # prints: foo returned 'this is my data'- You may assign data to global variables, and then refer to those variables in the caller.
foo() { return="this is my data" } foo echo "foo returned '$return'"
The drawback of this method is that if the function is executed in a subshell, then the assignment to a global variable inside the function will not be seen by the caller. This means you would not be able to use the function in a pipeline, for example.
- Your function may write its data to a file, from which the caller can read it.
foo() { echo "this is my data" > "$1" } # This is NOT solid code for handling temp files! tmpfile=$(mktemp) # GNU/Linux foo "$tmpfile" echo "foo returned '$(<"$tmpfile")'" rm "$tmpfile" # If this were a real program, there would have been error checking, and a trap.- The drawbacks of this method should be obvious: you need to manage a temporary file, which is always inconvenient; there must be a writable directory somewhere, and sufficient space to hold the data therein; etc. On the positive side, it will work regardless of whether your function is executed in a subshell.
For more information about handling temporary files within a shell script, see FAQ 62. For traps, see SignalTrap.