bugThe GNU Bourne-Again SHell - Bugs: bug #67326, Bash 5.3: Problem with new...

 
 

bug #67326: Bash 5.3: Problem with new in-process command substitution ${..} on macOS

Submitter:  None
Submitted:  Wed 16 Jul 2025 02:07:39 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  None Open/Closed:  Open
* Mandatory Fields

Post a Comment

Add a New Comment Rich Markup
   

Discussion

Jump to the original submission

Fri 18 Jul 2025 04:04:21 PM UTC, comment #7: 

I made these changes in the bash devel branch.

Chet Ramey <chet>
Group administrator
Thu 17 Jul 2025 02:38:48 PM UTC, comment #6: 


> I might be misunderstanding something here, but this behaviour might be common to BSD systems too: https://stackover ... ow.com/a/73752984


Well, it's a mixed bag.

OpenBSD 6 and 7 work using both shm_mkstemp and shm_open.

NetBSD 10 doesn't use those functions because they're in a separate library bash doesn't link with.

FreeBSD 14 works because it has memfd_create. FreeBSD 13 works like macOS, but the call fails because it doesn't like the O_NOFOLLOW flag, which is useful to avoid filename spoofing. Since shm_open fails, the code falls back to an anonymous regular file.

macOS accepts O_NOFOLLOW, but fails if the pathname (which uses $TMPDIR if defined) exceeds 31 characters. If you use the standard macOS TMPDIR, which is commonly something like /var/folders/x_/long-character-string/T/, you'll exceed that limit and shm_open will fail -- the limit is shorter than the _PC_PATH_MAX that bash checks for. So $TMPDIR is why some people see this error and some don't.

Linux shm_open works as long as the filename has one leading slash and no other slashes; it doesn't exist in the file system.

The best way to go is to just use memfd_create, shm_mkstemp, and an anonymous regular file, in that order, bypassing shm_open altogether.

Chet Ramey <chet>
Group administrator
Thu 17 Jul 2025 12:42:06 PM UTC, comment #5: 

comment #3:

> It seems like you can't write to any shared memory segment you open with shm_open(2), even if it returns a valid file descriptor. This makes macOS shm_open useless for this purpose, and is a weird difference from other systems.


I might be misunderstanding something here, but this behaviour might be common to BSD systems too: https://stackover ... ow.com/a/73752984

Carlo Cabrera <carlocab>
Thu 17 Jul 2025 12:10:54 PM UTC, comment #4: 

Sorry for the delay in getting back to you.

Confirming that building bash from source by running ./configure, then editing config.h and commenting out the line:

#define HAVE_SHM_OPEN 1

before running make solves the problem.

Thank you!

Anonymous
Wed 16 Jul 2025 03:37:21 PM UTC, comment #3: 

OK, I was able to reproduce it, after playing around with different values for the `name' parameter, but it's discouraging.

It seems like you can't write to any shared memory segment you open with shm_open(2), even if it returns a valid file descriptor. This makes macOS shm_open useless for this purpose, and is a weird difference from other systems.

The easiest fix, for now at least, is to edit config.h and comment out the line that reads

#define HAVE_SHM_OPEN 1

while I write a test for this at configure time.

Chet Ramey <chet>
Group administrator
Wed 16 Jul 2025 02:51:36 PM UTC, comment #2: 

I am one of those who cannot reproduce this on my macOS systems (15.5).

The stdout for a nofork command substitution is an anonymous file. The code tries memfd_create(), shm_mkstemp(), and shm_open(), in that order, before falling back to using a regular file.

My macOS systems don't have the first two, and shm_open() fails, so the code ends up using mkstemp() to create a temporary file.

I'm not sure which device is not configured here -- is that something that writes generate (since these are all write errors)? I'll play around and see if I can reproduce it.

Chet Ramey <chet>
Group administrator
Wed 16 Jul 2025 02:09:54 PM UTC, comment #1: 

Should have added:

Initial discussion on r/bash: https://www.reddi ... first_huh_moment/

Subsequent discussion on Homebrew's discussion forum: https://github.co ... /discussions/6285


Anonymous
Wed 16 Jul 2025 02:07:39 PM UTC, original submission:  

Hello. I believe there might be a problem with the new ${...} command substitution ability in bash 5.3. I can repeatedly produce an error on macOS Sequoia (15.5) on two different machines (one an M1 Mini, the other an M4 Macbook Pro), both using Homebrew bash and with bash compiled directly from source downloaded from gnu.org. Note that in discussion on r/bash and on the Homebrew discussions page, some other users do see this or similar issues, while others don't.

The issue:

bash-5.3$ export TEST=aaabbb
bash-5.3$ echo $( sed 's/a/b/g' <<< $TEST ; )
bbbbbb
bash-5.3$ echo ${ sed 's/a/b/g' <<< $TEST ; }
sed: stdout: Device not configured

bash-5.3$ echo ${| sed 's/a/b/g' <<< $TEST ; }
bbbbbb

Note that whatever I attempt to execute in ${..} produces the same error:

bash-5.3$ echo ${ echo hello; }
-bash: echo: write error: Device not configured

bash-5.3$ echo ${ cat <<< hello; }
cat: write error: Device not configured

bash-5.3$ echo ${ sed 's/e/3/' <<< hello; }
sed: couldn't flush stdout: Device not configured

I have tried launching bash with:

env -i /opt/homebrew/bin/bash --norc --noprofile

but get the same errors when running the above tests.

As mentioned above, I have also compiled bash from scratch using http://ftp.gnu.or ... h/bash-5.3.tar.gz and launched it as above (env -i, norc, noprofile) but get the same errors.

In case it's helpful (the first bash is Homebrew's, the second is my local build):

bash-5.3$ sw_vers
ProductName:            macOS
ProductVersion:         15.5
BuildVersion:           24F74

bash-5.3$ /opt/homebrew/bin/bash --version
GNU bash, version 5.3.0(1)-release (aarch64-apple-darwin24.4.0)
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

bash-5.3$ ~/Code/packages/bash/bash-5.3/bash --version
GNU bash, version 5.3.0(1)-release (aarch64-apple-darwin24.5.0)
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


Anonymous

 

Attached Files

This item currently has no attached files.

(Note: upload size limit is set to 4.0MiB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

 

Dependencies

This item does not depend on any other items.

No items depend on this one.

 

Mail Notification Carbon-Copy List

Carbon-Copy List
  • -email is unavailable- added by carlocab (Posted a comment)
  • -email is unavailable- added by chet (Posted a comment)
  •  

    Votes

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

    History

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-07-18 chet StatusIn Progress Fixed
    2025-07-17 chet StatusConfirmed In Progress
    2025-07-16 chet StatusNone Confirmed

    Back to the top

    Powered by Savane 3.16-598c.
    Corresponding source code