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