> I'd run `ldd' or equivalent to check which shared libraries that instance > of bash has linked.
This might be my ignorance, but I don't know if this works, as readline is statically linked to bash? At the very least, `ldd bash` did not seem to provide useful output. I have seen recommendations of `nm -D /bin/bash | grep rl_` which does seem to work to confirm whether bash contains the necessary `rl_print_keybindings` symbol. Regardless, I think I have identified my particular problem: - The initial source of the error is a Python call to `subprocess.Popen` with `shell=True` set. - According to the `subprocess.Popen` documentation, `shell=True` *should* perform the equivalent of `['/bin/sh', '-c', args[0], args[1], ...]`. - Setting `shell=False` (such that `args[0]` is called directly) sidesteps the error, suggesting `/bin/sh -c` is at fault. That said, my attempts to find out the exact shell type and version that Python calls went nowhere. Outside of the Python process, I did confirm `/bin/sh` correctly links to bash 5.3 and contains the expected symbols. But, I wasn't able to figure out why this fact changes when using a Python subprocess, because the very act of calling `subprocess.Popen` with `shell=True` triggers the error. Even `shell=False` + `bash --version` seems to trigger the error, making things trickier to debug. Regardless, I think this has gone beyond the scope of the readline project, so thank you for identifying the root cause. I'll try to propagate this information to others running into the `rl_print_keybindings` error. Kindly, Joshua On Thu, Jul 24, 2025 at 9:18 AM Chet Ramey <[email protected]> wrote: > > On 7/24/25 9:07 AM, Joshua Newton wrote: > > > Just to verify I'm understanding correctly, the recommendation is that > > both bash and readline should be updated in lockstep, and so by > > attempting to hold back readline but not bash, I'm just exacerbating > > the problem? (i.e. bash 5.3 + readline 8.2 == X) > > Yes. If you get an error like this, a program (sh) is trying to satisfy > an unresolved symbol (rl_print_keybinding), but it's not present in > any of the libraries it has linked. Since this symbol was introduced in > readline-8.3, it's logical to conclude that bash-5.3 is trying to use > readline-8.2. > > > What is strange to me is that, in my initial comparison between > > passing and failing runs, I noticed that both bash and readline were > > getting updated to 5.3 and 8.3 in lockstep, and yet the error still > > occurred: https://www.diffchecker.com/cn6N5NUb/. > > I'd run `ldd' or equivalent to check which shared libraries that instance > of bash has linked. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
