There are a lot of ways to exit a script.
VAR=$(FUNCTION) || kill -"$(($?&127))" 0
...might be one way. It should pass on to the parent shell's process group whatever the return is from FUNCTION
. It's not really fleshed out, but you can easily get the return from a command substitution if that is what you are asking. Else if you want suggestions about assigning a variable, well, from within a current shell function you can do it like:
fn(){ var=x; }; fn; echo "$var"
x
If it must be some command's output then you're talking about layered evaluation. You really need to trust that output, or else you need to capture the entire stream, in which case you'd better be sure about when to expect it. Such things are usually done with pipes - which is how command substitutions work - well, that and subshells, of course. Just as the shell does, you have to read
the data in, as is elsewhere suggested.
I like to use my own little pipe - I write a little at a time to the pipe's buffer and read it in again when I'm ready.
fn(){ echo hey; read hey; } <> <(:) >&0
fn; echo "$hey"
hey
...I guess I should mention that if you follow this last example you should take special care not to fill the buffer. Only write a little at a time, and read it in as soon as you can. On practically any system you can count on a baseline 512 byte buffer - which isn't much - but they are usually bigger.
If you're not careful, then, as the owner of both ends of that pipe, your shell won't receive any frustrated quit signals from any other process when it deadlocks, and it will just be stuck forever. I never point the output of any non-builtin command at one of those file-descriptors unless I've already forked off a reader process to drain the pipe as necessary.
Its stuff like that which makes same process messaging difficult - you have to manage it meticulously, in perfect synchronicity, and track all the separate threads of a task simultaneously. That's why shells fork.
source
command lets you run a file without spawning a subshell.