On 7/23/19 11:40 AM, Sam Liddicott wrote:
>
> On Tue, 23 Jul 2019 at 16:35, Chet Ramey <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 7/23/19 11:20 AM, Sam Liddicott wrote:
> >
> > On Tue, 23 Jul 2019 at 16:15, Sam Liddicott <[email protected]
> <mailto:[email protected]>
> > <mailto:[email protected] <mailto:[email protected]>>> wrote:
> >
> >
> >
> > On Tue, 23 Jul 2019 at 16:13, Chet Ramey <[email protected]
> <mailto:[email protected]>
> > <mailto:[email protected] <mailto:[email protected]>>> 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?
So the difference is between cases 1 and 3? That's the difference between
using the {var} syntax and using an explicit file descriptor.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
