Re: printf -u "$fd"?

[Chet Ramey]

On 5/21/24 11:14 AM, Zachary Santer wrote:
> 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? 

I'm genuinely curious how you got that from what I said, especially since
devel has gotten changes since I released bash-5.3-alpha.

> Do you create patches from devel and apply them to
> master?

Sort of, I take the code changes from the appropriate devel commit and
generate patches against the previous patch level. Sometimes devel and
previous-release diverge pretty  wildly, so it's not always
straightforward. Then I apply the patches to master and push them as
separate commits.

> I guess, to be more clear, master is in the history of
> bash-5.3-alpha,

Yes, I apply the bash testing versions to the last stable release so
people can, if they wish, see what's changed at a high level. Then I'll
push bash-5.3-beta on top of alpha, and so on.

> so I assume master will just fast-forward to that
> point when you're happy with bash-5.3.

Yes.

> 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.

It's how I set it up when I inherited the git repository. master has always
been a history of release versions.

> > > 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.

I haven't committed to doing anything with how coprocs are reaped, and if I
do it will certainly not be before bash-5.3.


> 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 haven't returned to it, but kre's syntax is reasonable. The problem with
doing it is described in

https://lists.gnu.org/archive/html/bug-bash/2024-02/msg00194.html

so it would take more work and thought, and it's not  a priority.

> 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.

That depends on your /dev/fd implementation. There's nothing in that
command that bash could affect.

> > > 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.

No, I don't think it's something I'm going to implement.

--
``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/