Dear list,
I found that bash tries to close the same fd twice, consecutively. I’m using
Mac OS X Yosemite, and bash is the newest available (bash-master from
http://tiswww.case.edu/php/chet/bash/bashtop.html yesterday).
To reproduce the phenomenon, just run this shell script.
— begin ---
P.S. Here is the output of bash version -l
GNU bash, version 4.3.42(1)-release (x86_64-apple-darwin14.5.0)
—
Yoriyuki Yamagata
National Institute of Advanced Science and Technology (AIST), Senior Researcher
http://staff.aist.go.jp/yoriyuki.yamagata/en/
On Fri, Dec 11, 2015 at 2:40 AM, Yoriyuki Yamagata <
yoriyuki.yamag...@aist.go.jp> wrote:
> Dear list,
>
> I found that bash tries to close the same fd twice, consecutively. I’m
> using Mac OS X Yosemite, and bash is the newest available (bash-master from
>
On 12/11/15 12:40 AM, Yoriyuki Yamagata wrote:
> Dear list,
>
> I found that bash tries to close the same fd twice, consecutively. I’m using
> Mac OS X Yosemite, and bash is the newest available (bash-master from
> http://tiswww.case.edu/php/chet/bash/bashtop.html yesterday).
That's
Regarding my last email, instead of a "break;" it should be a "continue;".
Just realized that xtrace might not always be last in $SHELLOPTS, so
it would break out of the while loop and stop the parsing of the rest
of the options.
$ cat file.c
int main()
{
system("env");
}
$ gcc
On 12/11/2015 06:42 AM, Chet Ramey wrote:
> On 12/11/15 12:40 AM, Yoriyuki Yamagata wrote:
>> Dear list,
>>
>> I found that bash tries to close the same fd twice, consecutively. I’m
>> using Mac OS X Yosemite, and bash is the newest available (bash-master from
>>
On 11 Dec 2015 07:06, Eric Blake wrote:
> On 12/11/2015 06:42 AM, Chet Ramey wrote:
> > On 12/11/15 12:40 AM, Yoriyuki Yamagata wrote:
> >> Dear list,
> >>
> >> I found that bash tries to close the same fd twice, consecutively. I’m
> >> using Mac OS X Yosemite, and bash is the newest available
Quoting Stephane Chazelas:
setuid bash will ignore SHELLOPTS (and drop privileges except
for the patched Debian version). In your case, since you're
doing a setuid(0), bash is no longer called as setuid, so can't
detect it.
Correct.
So you've got a shell started as root with the environment
