[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bash doesn't close-on-exec if its input source is dup()ed

From: Paul Jarc
Subject: bash doesn't close-on-exec if its input source is dup()ed
Date: 15 Dec 2000 18:39:11 -0000

Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' 
-D_FILE_OFFSET_BITS=64  -I.  -I. -I./include -I./lib -I/usr/include -O2 
-march=i386 -mcpu=i686
uname output: Linux multivac.student.cwru.edu 2.2.16 #1 SMP Tue Jul 18 14:44:21 
EDT 2000 i686 unknown
Machine Type: i386-redhat-linux-gnu

Bash Version: 2.04
Patch Level: 11
Release Status: release

        In input.c, check_bash_input() dup()s bash's input fd if the script
        tries to use that fd in a redirection.  But the new fd for bash's
        input doesn't get its close-on-exec flag set.
        This affects non-interactive shells.  For interactive shells, there
        is a different problem: if you redirect 255 (or whatever), it won't
        be dup()ed first, and something goes wrong with job control until you
        redirect 255 again back to the tty it was reading from before.  The
        rest of this report deals only with the non-interactive problem.

        #!/bin/bash -x
        ls -l /proc/$$/fd        # list bash's descriptors
        ls -l /proc/self/fd      # list those without close-on-exec
        exec 255< /dev/null      # assuming 255 is the script fd
        ls -l /proc/$$/fd        # show the new script fd
        ls -l /proc/self/fd      # the new script fd isn't inherited by kids...
        exec ls -l /proc/self/fd # but it is retained by exec

        Around line 207 of input.c, add this line:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]