On Tue, 23 Jul 2019 at 16:35, Chet Ramey <chet.ra...@case.edu> wrote:
> On 7/23/19 11:20 AM, Sam Liddicott wrote: > > > > On Tue, 23 Jul 2019 at 16:15, Sam Liddicott <s...@liddicott.com > > <mailto:s...@liddicott.com>> wrote: > > > > > > > > On Tue, 23 Jul 2019 at 16:13, Chet Ramey <chet.ra...@case.edu > > <mailto:chet.ra...@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
