On Thu, Oct 19, 2006 at 04:02:36PM -0400, Chet Ramey wrote:
> Mike Stroyan wrote:
>
> > move_to_high_fd() only avoid open file descriptors if the
> > check_new parameter is non-zero. open_shell_script() calls
> > move_to_high_fd() with a check_new value of 0. The other two callers
> > of the f
Mike Stroyan wrote:
> move_to_high_fd() only avoid open file descriptors if the
> check_new parameter is non-zero. open_shell_script() calls
> move_to_high_fd() with a check_new value of 0. The other two callers
> of the function do pass in a check_new value of 1.
>
Aha! I missed the most r
On Thu, Oct 19, 2006 at 03:33:37PM -0400, Chet Ramey wrote:
> Mike Stroyan wrote:
>
> > Looking at open_shell_script() in shell.c and move_to_high_fd() in
> > general.c, I find that the code will force the use of fildes 255,
> > (HIGH_FD_MAX), for reading the shell script when getdtablesize() re
Mike Stroyan wrote:
> Looking at open_shell_script() in shell.c and move_to_high_fd() in
> general.c, I find that the code will force the use of fildes 255,
> (HIGH_FD_MAX), for reading the shell script when getdtablesize() reports
> that the maximum allowed file descriptor value is greater than
I was recently helping to debug a problem with an application getting
bad file descriptor errors when run from a shell wrapper script. The
cause was that the parent process left fildes 255 open for the child
process, but the bash wrapper script was causing fildes 255 to be
closed.
Looking at
