Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Morgan McClure <mcclure.morgan@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Incorrect passing of argc argv with multiple redirects
Date: Tue, 30 Jul 2019 10:08:54 -0700
Lines: 44
Approved: bug-bash@gnu.org
Message-ID: <mailman.281.1564507949.1985.bug-bash@gnu.org>
References: <CANY-LFLTkqOyooA522KwuB1JEiaiUQ=N-5XEVWxueO14WLWWvQ@mail.gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Precedence: list
Xref: csiph.com gnu.bash.bug:15280

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