Re: printf -u "$fd"?

[Zachary Santer]

On Tue, May 21, 2024 at 3:06 PM Chet Ramey <chet.ramey@case.edu> wrote:
>
> 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.

Changes I assumed would make it into master while master is bash-5.3.
It sounded like you didn't want to implement anything in devel right
now that wasn't going to make it into bash-5.3. I probably didn't
phrase that very well.

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

And there are some source code things that are different under devel
than in master that aren't meant to ever make it into master, if I
remember correctly? Kind of trying to come up with a better way to do
this that would allow master and devel to continue to serve the
purposes they do now. If you're at all interested.

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

Honestly, I might've been looking at a limitation of MSYS2.

In my Rocky Linux 9.1 VM:
$ bash --version
GNU bash, version 5.1.8(1)-release [...]
$ exec {fd_A}> >( cat > file_A.txt )
$ exec {fd_B}> >( cat > file_B.txt )
$ printf 'words\n' | tee /dev/fd/"${fd_A}" /dev/fd/"${fd_B}"
words
$ exec {fd_A}>&- {fd_B}>&-
$ cat file_A.txt
words
$ cat file_B.txt
words
$ exec {fd_A}> >( tr 'w' 'W' > file_A.txt )
$ exec {fd_B}> >( tr 'w' 'W' > file_B.txt )
$ exec {fd_A}>&- {fd_B}>&-
$ cat file_A.txt
$ cat file_B.txt
$

God knows what I was trying to do the first time, or what's going on
with the second set of procsubs there, but I didn't get "tee:
/dev/fd/N: No such file or directory" like I was expecting. Think I'll
leave this bit of the discussion to the people who know what they're
talking about.

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

Eh well, I thought it would be valuable.