On 8/23/23 9:50 AM, Zachary Santer wrote:
In the Bash man page:
varredir_close
If set, the shell automatically closes file descriptors assigned
using the {varname} redirection syntax (see REDIRECTION above) instead of
leaving them open when the command completes.
I feel like the man p
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 wo
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 we
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.
> $ s
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
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.
On Wed, 23 Aug 2023, 12:20 Greg Wooledge, wrote:
> > echo Hi {X}>/dev/null
> > ls -l "/proc/$$/fd/$X"
>
> That's a really strange example. I wonder what would lead someone to
> write that particular redirection.
Oh I merely wanted to point out that the redirection persists beyond the
echo comm
On Wed, Aug 23, 2023 at 12:05:42PM +1000, Martin D Kealey wrote:
> On Wed, 23 Aug 2023, 05:29 Greg Wooledge, wrote:
>
> > Excuse me now, while I go and close several open FDs in the shell where
> > I tested something the other day, which I had no idea were left open.
> >
>
> It's even worse than
On Wed, 23 Aug 2023, 05:29 Greg Wooledge, wrote:
> Excuse me now, while I go and close several open FDs in the shell where
> I tested something the other day, which I had no idea were left open.
>
It's even worse than that; try:
echo Hi {X}>/dev/null
ls -l "/proc/$$/fd/$X"
-Martin
>
On Tue, Aug 22, 2023 at 02:59:14PM -0400, Dale R. Worley wrote:
> The "{var}>..." mechanism *assigns* to $var, rather than
> taking its existing value.
... oh. Well, today I learned something.
Excuse me now, while I go and close several open FDs in the shell where
I tested something the other da
On 8/22/23 2:59 PM, 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
assemble a command string however you want. But is there a direct way
to write it? The "{var}>..." mechanism *assi
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
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 existin
On Sun, 20 Aug 2023, 14:15 Grisha Levit, wrote:
> [...] it would probably make sense to undo them if the exec fails and the
> shell is not going to exit.
>
Just one question: how?
The sequence of dup2() and close() calls has to occur before the execve()
call. Whilst they could be undone by usin
On 8/20/23 12:15 AM, Grisha Levit wrote:
exec {foo}>/tmp/foo
exec "${foo}"<&-
Looks like bash doesn't undo redirections if the exec fails -- so the shell
terminates because the redirection closed stdin.
I agree it would probably make sense to undo them if the exec fails and
On 8/19/23 1:37 PM, jleivent wrote:
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
Using exec to close a file descriptor in a variable crashes
bash. It doesn't matter how the fd got into the variable, but
the likely usage is with the {varname}
On Sat, Aug 19, 2023, 16:42 jleivent wrote:
> bash: exec: 10: not found
> But even that shouldn't cause the shell to terminate if the
> target isn't found, so maybe this is two bugs?
>
> Repeat-By:
>
> exec {foo}>/tmp/foo
> exec "${foo}"<&-
>
Looks
On Sat, Aug 19, 2023 at 01:37:31PM -0400, jleivent wrote:
> Repeat-By:
>
> exec {foo}>/tmp/foo
> exec "${foo}"<&-
Remove the quotes and the $ and it should work.
exec {foo}<&-
The way you've got it is essentially:
exec "$foo" <&-
This does't make bash "crash". It'
17 matches
Mail list logo
