So I think I've discovered a bug with the way that bash handles passing
argc and argv to programs in the presence of multiple redirects.
For this testing, my C source file is just the following:
int main(int argc, char * argv[]) {
return argc;
}
For the purposes of testing, I comment out one or the other of those lines
and run the following:
./a.out; echo $?
returns 1 as expected
./a.out foo; echo $?
returns 2 as expected
./a.out foo > /dev/null; echo $?
returns 2 as expected
./a.out foo > /dev/null 2&>1; echo $?
returns 3 NOT as expected
If I modify and recompile the program to return the contents of argv I can
see that the contents of that 3rd argument is the string "2".
This behavior was tested and not observed with zsh and seems dangerous
(since a program taking variable length arguments might behave differently
only when the user tries to silence output). I could /maybe/ see an
argument for it being the string "2&>1" but "2" is very much incorrect.
I've tested on:
OSX 10.14.6 with the provided bash shell:
"GNU bash, 3.2.57(1)-release (x86_64-apple-darwin18)"
as well as latest from brew:
"GNU bash, version 5.0.7(1)-release (x86_64-apple-darwin18.5.0)"
Also reproduced on CentOS:
"2.6.32-504.30.3.el6.x86_64 #1 SMP Wed Jul 15 10:13:09 UTC 2015 x86_64
x86_64 x86_64 GNU/Linux"
"GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)"
Is this known behavior? I've been unable to locate documentation to this
effect and it seems highly unexpected especially given that other shells
don't appear to do it.
-Morgan
