Re: using exec to close a fd in a var crashes bash
On 2023-08-23 at 10:34 -0400, Greg Wooledge wrote:
> So... {var}> redirections were introduced in bash 4.1, and
> varredir_close in bash 5.2. That means that in all versions from
> bash 4.1 to 5.1, you will need the separate "exec {fd}>&-" to close
> the temp FD. At this point, it hardly seems worthwhile to make use
> of a feature that only works in bash 5.2, which is surely a tiny
> fraction of the set of installed bash instances in the world.
>
> Perhaps in a decade or so, when bash 5.2+ instances are the majority,
> it will make sense to expect that feature to exist. But you'd still
> need fallback code for the rest.
>
> Then again... leaving an FD open in a shell script usually won't
> matter, because the script will exit, and that'll just take care of
> it. The only times it actually matters are long-running bash
> processes --either interactive shells, or some kind of weird daemon
> that's been implemented in bash for some reason -- or scripts that
> open and (fail to) close lots of temp FDs in a loop.
>
> So, unless you're using this feature in an interactive shell function
> or programmable completion or something, I guess it can mostly be
> ignored.
You can just toss out
shopt -s varredir_close 2> /dev/null || true # Close varredir_close on bash
5.2+
at the top of the script, and have correct behavior with recent bash, and
small-fd-leak-but-otherwise-working on previous versions that are 4.1+.
Re: remove empty '' in ${var@Q} result?
On 8/20/23 12:20 PM, Clark Wang wrote: I did. It's on the list of possible things for the next version. Since it's only a cosmetic issue, it's not a high priority. Hi Chet, Is it possible to fix this in 5.3? It's not a bug, and it's not a high priority. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: nofork comsub in PS1 + ignoreeof
On 8/19/23 4:23 AM, Grisha Levit wrote: When a nofork command substitution is in PS1 and ignoreeof is enabled, (sufficiently repeated) EOF doesn't actually cause the shell to exit: Thanks for the report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: using exec to close a fd in a var crashes bash
On Aug 23 2023, Greg Wooledge wrote: > Then again... leaving an FD open in a shell script usually won't matter, > because the script will exit, and that'll just take care of it. The > only times it actually matters are long-running bash processes -- either > interactive shells, or some kind of weird daemon that's been implemented > in bash for some reason -- or scripts that open and (fail to) close lots > of temp FDs in a loop. It will also cause the open FD to be passed to all subsequent commands, and keeps a reference to the underlying file, which may affect EOF processing if the file is a pipe. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: using exec to close a fd in a var crashes bash
On Wed, Aug 23, 2023 at 09:50:36AM -0400, Zachary Santer wrote:
> From the NEWS file [1]:
>
> o. The new `varredir_close' shell option causes bash to automatically close
>file descriptors opened with {var}redirection unless they're arguments to the `exec' builtin.
Hmm, interesting.
> $ shopt -s varredir_close
> $ printf 'words\n' {fd}>&1 1>&2 2>&$fd {fd}>&-
> words
> $ ls /dev/fd
> 0 1 2 3
Of course, you can drop the {fd}>&- there, because it does nothing. With
or without varredir_close, either way, it does nothing.
So... {var}> redirections were introduced in bash 4.1, and varredir_close
in bash 5.2. That means that in all versions from bash 4.1 to 5.1, you
will need the separate "exec {fd}>&-" to close the temp FD. At this
point, it hardly seems worthwhile to make use of a feature that only
works in bash 5.2, which is surely a tiny fraction of the set of installed
bash instances in the world.
Perhaps in a decade or so, when bash 5.2+ instances are the majority,
it will make sense to expect that feature to exist. But you'd still
need fallback code for the rest.
Then again... leaving an FD open in a shell script usually won't matter,
because the script will exit, and that'll just take care of it. The
only times it actually matters are long-running bash processes -- either
interactive shells, or some kind of weird daemon that's been implemented
in bash for some reason -- or scripts that open and (fail to) close lots
of temp FDs in a loop.
So, unless you're using this feature in an interactive shell function
or programmable completion or something, I guess it can mostly be ignored.
Re: using exec to close a fd in a var crashes bash
On Wed, Aug 23, 2023 at 1:48 AM Martin D Kealey
wrote:
> Chopping and changing behaviour in "permanent" releases creates a
> maintenance nightmare.
>
Well now with Bash 5.2, we've got the varredir_close shell option,
something savvy shell programmers would probably just always use, like
lastpipe.
>From the NEWS file [1]:
o. The new `varredir_close' shell option causes bash to automatically close
file descriptors opened with {var}&1 1>&2 2>&$fd {fd}>&-
words
$ ls /dev/fd
0 1 10 2 3
$ exec {fd}>&-
$ ls /dev/fd
0 1 2 3
$ shopt -s varredir_close
$ printf 'words\n' {fd}>&1 1>&2 2>&$fd {fd}>&-
words
$ ls /dev/fd
0 1 2 3
$ exec {fd}> this_file.txt
$ printf 'words\n' >&$fd
$ printf 'other words\n' >&$fd
$ exec {fd}>&-
$ cat this_file.txt
words
other words
Zack
[1]: https://git.savannah.gnu.org/cgit/bash.git/tree/NEWS
Re: using exec to close a fd in a var crashes bash
On Tue, Aug 22, 2023, 21:00 Dale R. Worley wrote:
> Is there any way to write a redirection "Redirect the fd whose number is
> in $FOO to file /foo/bar?" OK, you can write 'bash -c "..."' and
>
i think there was a ' duplicate ' directive .. use that
assemble a command string however you want. But is there a direct way
> to write it? The "{var}>..." mechanism *assigns* to $var, rather than
> taking its existing value.
>
> Dale
>
>
