Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #15280 > unrolled thread
| Started by | Morgan McClure <mcclure.morgan@gmail.com> |
|---|---|
| First post | 2019-07-30 10:08 -0700 |
| Last post | 2019-07-30 10:08 -0700 |
| Articles | 1 — 1 participant |
Back to article view | Back to gnu.bash.bug
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Incorrect passing of argc argv with multiple redirects Morgan McClure <mcclure.morgan@gmail.com> - 2019-07-30 10:08 -0700
| From | Morgan McClure <mcclure.morgan@gmail.com> |
|---|---|
| Date | 2019-07-30 10:08 -0700 |
| Subject | Incorrect passing of argc argv with multiple redirects |
| Message-ID | <mailman.281.1564507949.1985.bug-bash@gnu.org> |
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
Back to top | Article view | gnu.bash.bug
csiph-web