Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Chet Ramey <chet.ramey@case.edu>
Newsgroups: gnu.bash.bug
Subject: Re: leaks fd for internal functions but not external command
Date: Tue, 23 Jul 2019 16:57:57 -0400
Lines: 94
Approved: bug-bash@gnu.org
Message-ID: <mailman.2112.1563915484.2688.bug-bash@gnu.org>
References: <CAOj-5WDk=8kt=J8wO23giFVWRp5=_GbCNB2HQO87Upc4kkTg+g@mail.gmail.com> <5c34ecd5-c8b2-7000-46bc-1bbe3f71f163@case.edu> <CAOj-5WCFbUoU1x2aUvidT1opUbGeG2jFSaM__ch=SUAfzQbQ9w@mail.gmail.com> <78679ee9-fdaf-5180-d32f-81d92b936538@case.edu> <CAOj-5WBei5KMar7c967=jSwZRsW-Rz-0iL20TQMeuQoz61rfkw@mail.gmail.com> <CAOj-5WA_URW5b7a2EU+rR=T_wbTDEpOM_PSo9yNyU-Dqj+cWaA@mail.gmail.com> <f6acdcca-4c7c-b05c-004d-9b8ceab1e169@case.edu> <CAOj-5WA0b5Lv9GhXkK6gwoS1uVd2B1a0048tZ6sUNnhVHS+ixg@mail.gmail.com> <40109c28-c4a8-2ea0-cc77-e46a584dc011@case.edu> <CAOj-5WBX2h-nwO-u9ocWitmBQ-o=560dJFZw2xLeojNS5ZKs8Q@mail.gmail.com> <38bf161d-8170-69ba-77d0-638aa0852ad9@case.edu>
Reply-To: chet.ramey@case.edu
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cc: chet.ramey@case.edu, bug-bash@gnu.org, bash@packages.debian.org
To: Sam Liddicott <sam@liddicott.com>
Envelope-to: bug-bash@gnu.org
Openpgp: preference=signencrypt
Autocrypt: addr=chet.ramey@case.edu; prefer-encrypt=mutual; keydata= xsDiBEEOsGwRBACFa0A1oa71HSZLWxAx0svXzhOZNQZOzqHmSuGOG92jIpQpr8DpvgRh40Yp AwdcXb8QG1J5yGAKeevNE1zCFaA725vGSdHUyypHouV0xoWwukYO6qlyyX+2BZU+okBUqoWQ koWxiYaCSfzB2Ln7pmdys1fJhcgBKf3VjWCjd2XJTwCgoFJOwyBFJdugjfwjSoRSwDOIMf0D /iQKqlWhIO1LGpMrGX0il0/x4zj0NAcSwAk7LaPZbN4UPjn5pqGEHBlf1+xDDQCkAoZ/VqES GZragl4VqJfxBr29Ag0UDvNbUbXoxQsARdero1M8GiAIRc50hj7HXFoERwenbNDJL86GPLAQ OTGOCa4W2o29nFfFjQrsrrYHzVtyA/9oyKvTeEMJ7NA3VJdWcmn7gOu0FxEmSNhSoV1T4vP2 1Wf7f5niCCRKQLNyUy0wEApQi4tSysdz+AbgAc0b/bHYVzIf2uO2lIEZQNNt+3g2bmXgloWm W5fsm/di50Gm1l1Na63d3RZ00SeFQos6WEwLUHEB0yp6KXluXLLIZitEJM0gQ2hldCBSYW1l eSA8Y2hldC5yYW1leUBjYXNlLmVkdT7CYQQTEQIAIQIbAwYLCQgHAwIDFQIDAxYCAQIeAQIX gAUCRX3FIgIZAQAKCRC7WGnwZOp0q069AKCNDRn+zzN/AHbaynls/Lvq1kH/RQCgkLvF8bDs maUHSxSIPqzlGuKWDxbOwE0EQQ6wbxAEAJCukwDigRDPhAuI+lf+6P64lWanIFOXIndqhvU1 3cDbQ/Wt5LwPzm2QTvd7F+fcHOgZ8KOFScbDpjJaRqwIybMTcIN0B2pBLX/C10W1aY+cUrXZ gXUGVISEMmpaP9v02auToo7XXVEHC+XLO9IU7/xaU98FL69l6/K4xeNSBRM/AAMHA/wNAmRB pcyK0+VggZ5esQaIP/LyolAm2qwcmrd3dZi+g24s7yjV0EUwvRP7xHRDQFgkAo6++QbuecU/ J90lxrVnQwucZmfz9zgWDkT/MpfB/CNRSKLFjhYq2yHmHWT6vEjw9Ry/hF6Pc0oh1a62USdf aKAiim0nVxxQmPmiRvtCmcJJBBgRAgAJBQJBDrBvAhsMAAoJELtYafBk6nSr43AAn2ZZFQg8 Gs/zUzvXMt7evaFqVTzcAJ0cHtKpP1i/4H4R9+OsYeQdxxWxTQ==
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
In-Reply-To: <CAOj-5WBX2h-nwO-u9ocWitmBQ-o=560dJFZw2xLeojNS5ZKs8Q@mail.gmail.com>
Content-Language: en-US
Precedence: list
Xref: csiph.com gnu.bash.bug:15218

On 7/23/19 12:12 PM, Sam Liddicott wrote:

> Given what you have explained as intentional, it the difference between 1
> and 2, but it is best understood as a 4-way difference, outlined here:
> 
> 1. {var} internal: fd remains open in parent
> 2. {var} external: fd closed in parent
> 3. numeric internal: fd closed in parent
> 4. numeric external: fd closed in parent
> 
> 1. {var} internal: fd remains open in parent
> bash -c 'echo 1 {_}>&2 2>&1 1>&${_} {_}<&- ; 
>         echo done ; lsof -p $$ | grep CHR'
> 
> 2. {var} external: fd closed in parent
> bash -c '/bin/echo 1 {_}>&2 2>&1 1>&${_} {_}<&- ; 
>         echo done ; lsof -p $$ | grep CHR'
> 
> 3. numeric internal: fd closed in parent
> bash -c 'echo 1 10>&2 2>&1 1>&10 10<&- ; 
>         echo done ; lsof -p $$ | grep CHR'
> 
> 4. numeric external: fd closed in parent
> bash -c '/bin/echo 1 10>&2 2>&1 1>&10 10<&- ; 
>         echo done ; lsof -p $$ | grep CHR'
> 
> You've indicated that {var} syntax leaves me an fd to do with what I wish.

Yes. The question is whether the {_}<&- should close the file descriptor
`permanently' or whether that close action should be undone because you're
not using `exec' and the file descriptor was created using the variable
assignment syntax. The latter is what bash does now.

> You've also explained what bash is doing that makes this untrue if the
> command was an external command.

Because you never open the file descriptor in the parent shell:
redirections happen in the child. The child process in case 2 (and 4)
can do what it wants with the file descriptor, and its view of the
file descriptor is the same as case 1 (and 3).

> I don't believe that this behaviour is *intended( to depend on the
> non-obvious detail of whether or not the command is external.

Why? There are plenty of things that depend on whether or not a command is
builtin, or whether it's run in the parent shell.

> 
> Given the coding pattern of wrapping external commands with functions that
> re-invoke using bash "command"; this can lead to unpredictable behaviours
> when such wrappers are active.
> 
> e.g. openssl() { LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/extra" *command*
> openssl "$@"; }
> 
> If that function is defined, I get a handle leak*, if it isn't and main
> openssl is called, I don't -- or from the other of view my handle got
> closed without my knowledge, so I can't use it as I wish.
> 
> Personally I would wish that "{var} internal" would also close the fd as it
> does for numeric fd and for external {var} fd, because if I really wanted
> to open an fd and have it hang around I would do a naked: exec {xxx}>&2 ;
> type of thing.

Sure. But there's not as good a reason to have that syntax otherwise. It's
just syntactic sugar, a way for historical shells to use file descriptors
greater than 9.

> I also think that based on your description of what bash is doing, it might
> be easier to fix by also closing in the parent, as I describe.
> 
> It would bring full consistency and avoid hard to detect and hard to
> code-around bugs.
> 
> Ultimately, unless {var} external is intended to behave different to {var}
> internal, then we have a consistency bug.

The internal/external difference doesn't really have anything to do with
the semantics of file descriptors or redirections per se; only that
redirections are performed in the child. There are multiple variations in
behavior depending on whether a command is executed in a subshell, and this
is one of them.

Ultimately, the difference is between cases 1 and 3 and retaining a handle
to the file descriptor instead of closing it when the command finishes.
Everything else is identical between the two commands. That was a design
choice. I don't see changing it now.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/