Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #15214 > unrolled thread
| Started by | Sam Liddicott <sam@liddicott.com> |
|---|---|
| First post | 2019-07-23 16:40 +0100 |
| Last post | 2019-07-23 16:40 +0100 |
| Articles | 1 — 1 participant |
Back to article view | Back to gnu.bash.bug
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: leaks fd for internal functions but not external command Sam Liddicott <sam@liddicott.com> - 2019-07-23 16:40 +0100
| From | Sam Liddicott <sam@liddicott.com> |
|---|---|
| Date | 2019-07-23 16:40 +0100 |
| Subject | Re: leaks fd for internal functions but not external command |
| Message-ID | <mailman.2084.1563896445.2688.bug-bash@gnu.org> |
On Tue, 23 Jul 2019 at 16:35, Chet Ramey <chet.ramey@case.edu> wrote:
> On 7/23/19 11:20 AM, Sam Liddicott wrote:
> >
> > On Tue, 23 Jul 2019 at 16:15, Sam Liddicott <sam@liddicott.com
> > <mailto:sam@liddicott.com>> wrote:
> >
> >
> >
> > On Tue, 23 Jul 2019 at 16:13, Chet Ramey <chet.ramey@case.edu
> > <mailto:chet.ramey@case.edu>> 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
Back to top | Article view | gnu.bash.bug
csiph-web