bug-bash
[Top][All Lists]
Advanced

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

Re: leaks fd for internal functions but not external command


From: Sam Liddicott
Subject: Re: leaks fd for internal functions but not external command
Date: Tue, 23 Jul 2019 16:40:03 +0100

On Tue, 23 Jul 2019 at 16:35, Chet Ramey <address@hidden> wrote:

> On 7/23/19 11:20 AM, Sam Liddicott wrote:
> >
> > On Tue, 23 Jul 2019 at 16:15, Sam Liddicott <address@hidden
> > <mailto:address@hidden>> wrote:
> >
> >
> >
> >     On Tue, 23 Jul 2019 at 16:13, Chet Ramey <address@hidden
> >     <mailto:address@hidden>> wrote:
> >
> >         On 7/23/19 11:11 AM, Sam Liddicott wrote:
> >
> >         > The report concerns the different behaviour with internal and
> >         external
> >         > operations.
> >
> >         Right. The close-on-exec is deliberate. That's how it was
> intended.
> >
> >
> >     Doesn't close-on-exec usually takes effect only on the process that
> >     does the exec?
> >     i.e. the fork that does the exec, not the parent process?
> >
> >
> > It got closed in the parent. The lsof is running for the parent, the main
> > process. /bin/echo has quit before the lsof runs.
>
> You mean case 2 in your original post? That's because redirections are
> performed in the child process forked to run /bin/echo, so the fd never
> exists in the parent process. I thought you were talking about case 1,
> with the builtin echo.
>

No doubt, but this report concerns the inconsistency.

Is using {xxx}>... suppose to give me a file handle I can use as I wish (as
you say), or not?

Using explicit descriptors e.g. 10>... behaves consistently whether the the
command is internal or external.

Having bash allocate the descriptor is not consistent.

Sam


reply via email to

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