# Re: [PATCH] Clean up file descriptors when calling hooks.

2 messages from 2005-12-08 to 2005-12-08. Participants: linux@horizon.com, Junio C Hamano.
Thread: https://gitlist.dev/t/2774

## linux@horizon.com, 2005-12-08 03:24

Subject: Re: [PATCH] Clean up file descriptors when calling hooks.
Message-ID: <20051208032428.8591.qmail@science.horizon.com>
URL: https://gitlist.dev/e/20051208032428.8591.qmail%40science.horizon.com

```
> A quick question.  I understand "not connected to the pushing
> connection" is desirable, but is there a reason you chose to
> leave them open to /dev/null, not close()d?

Because then the first open() in the hook will assign those fds,
confusing programs that try to use them for their traditional
purposes.  fd 2 (stderr) is of particular concern.

E.g. imagine if I ran gcc -c file.c, and it assigned file.c to fd 0,
file.h to fd1, and file.o to fd 2.   Then wants to print a warning
message... right into the middle of the binary.  (Oversimplified
example, because gcc is actually several separate programs, but
hopefully you get the idea.)

It's just safer to leave those fds open to a null device.

```

## Junio C Hamano, 2005-12-08 03:29

Subject: Re: [PATCH] Clean up file descriptors when calling hooks.
Message-ID: <7vr78omfkk.fsf@assigned-by-dhcp.cox.net>
URL: https://gitlist.dev/e/7vr78omfkk.fsf%40assigned-by-dhcp.cox.net
In-Reply-To: <20051208032428.8591.qmail@science.horizon.com>

```
linux@horizon.com writes:

> E.g. imagine if I ran gcc -c file.c, and it assigned file.c to fd 0,
> file.h to fd1, and file.o to fd 2.   Then wants to print a warning
> message... right into the middle of the binary.  (Oversimplified
> example, because gcc is actually several separate programs, but
> hopefully you get the idea.)
>
> It's just safer to leave those fds open to a null device.

Overdangerous example.  Do people realize hooks run without any
locking?

```