Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15220

Re: leaks fd for internal functions but not external command

Show key headers only | View raw

On 7/23/19 5:15 PM, Sam Liddicott wrote:
> I'm very surprised that you continue to insist that it should be a *design*
> decision that it should be hard for a script writer to be able to tell if a
> handle will be left open or not.

What? The design decision is that a file descriptor opened with {var} will
remain open after the command completes.

> What could be the rationale for such a design decision?

To make the redirection operator a little more useful than simple syntactic
sugar.

> The vague justification you provide "there are plenty of things that depend
> on whether or not a command is builtin, or whether it's run in the parent
> shell" is true but more relevant to an implementation constraint than a
> design decision.

An implementation constraint? That doesn't make any sense.

The bash documentation makes it pretty clear which commands are builtin and
the circumstances under which commands are run in child processes and which
are run by the shell itself.

> I'm confident that most of these things you hint at are too *avoid* the
> scripter needing to be aware of the difference between internal and
> external commands.

Bash doesn't make it particularly obscure about which commands are builtin,
and, as I said, the man page documents all of them.

The builtin commands all provide functionality that can't be duplicated
outside the shell itself, even the builtins that duplicate external
commands (e.g., printf -v). Someone who writes shell scripts should be
aware of what's builtin and what's not.

But that's not the problem here.

> 
> A design decision may well be to leave a variable handle open, but what
> *design* decision would add the proviso that it not be an external command?

This makes me believe that you have a fundamental misunderstanding about
how the shell operates.

The design decision is to leave the file descriptor open, as I said above.
It's left open in all cases. The difference is that commands that are run
from the file system perform redirections in the child process, and child
processes cannot affect their parent's environment. That means, among other
things, that a file descriptor that a child process opens does not affect
the parent's descriptor set. That has nothing to do with the behavior of
{var} per se; it's a consequence of the relationship between Unix
processes.

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/

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread

Thread

Re: leaks fd for internal functions but not external command Chet Ramey <chet.ramey@case.edu> - 2019-07-23 20:20 -0400

csiph-web