Bash – if env variable exists then exit out of script

The << construct introduces a shell here document that is treated as if it were a double-quoted string as it is read, so variables expand immediately as they are read by the shell. You would see this clearly if you enable a shell feature that tells you about undefined variables. I'll use that feature in the BASH shell here:

$ set -o nounset
$ echo "$a"
bash: a: unbound variable
$ bash <<EOF
> a=foo
> echo "$a"
> EOF
bash: a: unbound variable

To stop the shell from expanding variables in the here document as it is being read, you can either single-quote the tag or backslash every use of every variable:

$ bash <<'EOF'
> a=foo
> echo "$a"
> EOF
foo

$ bash <<EOF
> a=foo
> echo "\$a"
> EOF
foo

Note that the types of quotes used around the variable inside the here document have nothing to do with whether or not the variable is expanded by the shell as the here document is being read.

p.s. Always double-quote your variable expansions so that they don't trigger unintended GLOB file name matches.

p.p.s. Turn on undefined-variable checking in you shells, to catch your typing errors. This would have clued you in to your problem.

p.p.p.s. Don't use C shells for scripting. They have many bugs and inconsistencies

You can pretty easily get the return from any subshelled process by echoing its return out over its stdout. The same is true of process substitution:

while IFS= read -r -d $'\0' FILE || 
    ! return=$FILE
do    ARGS[ARGID++]="$FILE"
done < <(find . -type f -print0; printf "$?")

If I run that then the very last line - (or \0 delimited section as the case may be) is going to be find's return status. read is going to return 1 when it gets an EOF - so the only time $return is set to $FILE is for the very last bit of information read in.

I use printf to keep from adding an extra \newline - this is important because even a read performed regularly - one in which you do not delimit on \0 NULs - is going to return other than 0 in cases when the data it has just read in does not end in a \newline. So if your last line does not end with a \newline, the last value in your read in variable is going to be your return.

Running command above and then:

echo "$return"

OUTPUT

0

And if I alter the process substitution part...

...
done < <(! find . -type f -print0; printf "$?")
echo "$return"

OUTPUT

1

A more simple demonstration:

printf \\n%s list of lines printed to pipe |
while read v || ! echo "$v"
do :; done

OUTPUT

pipe

And in fact, so long as the return you want is the last thing you write to stdout from within the process substitution - or any subshelled process from which you read in this way - then $FILE is always going to be the return status you want when it is through. And so the || ! return=... part is not strictly necessary - it is used to demonstrate the concept only.