Re: printf -u "$fd"?

[Zachary Santer]

On Tue, May 21, 2024 at 9:01 AM Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 5/21/24 6:17 AM, Zachary Santer wrote:
>
> > I was wondering what the relationship between the devel and master
> > branches was.
>
> No mystery: the devel branch captures ongoing development, gets the latest
> bug fixes, and is where new features appear. The master branch is for
> stable releases.

But the devel branch won't get changes for bash versions beyond what's
in alpha right now? Do you create patches from devel and apply them to
master? I guess, to be more clear, master is in the history of
bash-5.3-alpha, so I assume master will just fast-forward to that
point when you're happy with bash-5.3. Meanwhile, devel is completely
off doing its own thing, in terms of the git commit history, Kind of
have a hard time wrapping my mind around that.

> > I saw that you turned MULTIPLE_COPROCS=1 on by default
> > under devel, but haven't touched the somewhat more substantial changes
> > that sounded forthcoming, from that whole conversation.
>
> Which one is that?

So this email[1] was just about the config-top.h change, I guess, but
in the prior one from you quoted there[2], you seemed to be
referencing only removing the coproc once both file descriptors
pointing to it have been closed by the user.

Additionally, I was hoping the discussion of having a way to make fds
not CLOEXEC without a loadable builtin[3][4] would get some more
attention. I want to say I tried to do 'tee /dev/fd/A /dev/fd/B' at
some point and didn't have the background knowledge to understand why
it wouldn't work.

> > So I take it
> > MULTIPLE_COPROCS=1 will be enabled in bash-5.3 but other potential
> > changes would come later?
>
> Probably, yes.
>
> > Do you keep a list of TODOs and things under consideration somewhere?
>
> I do, it's more of the `folder of ideas' style.

Did nosub[5] get in there? Just generalize how coproc fds get handled
into something that can be turned on or off for any fd.

[1] https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00149.html
[2] https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00105.html
[3] https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00085.html
[4] https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00100.html
[5] https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00087.html