I was just watching the discussion because I thought the existing behavior would never be changed as it behaved this way for a long time. However, I now think I should leave a comment because even Martin (who I believed was one of the careful people about backward compatibility as seen in [1,2]) seems to suggest a breaking change.
https://lists.gnu.org/archive/html/bug-bash/2022-11/msg00017.html https://lists.gnu.org/archive/html/bug-bash/2023-11/msg00150.html 2024年2月3日(土) 21:45 Martin D Kealey <mar...@kurahaupo.gen.nz>: > If that's how the documentation is interpreted, then clearly there's a bug > in the documentation, because this is almost never *useful* behaviour. This is not true. Before Bash 3.2, READLINE_LINE and READLINE_POINT were not supported, where Bash configurations used readline macros (something like « bind '"xxx": "\C-u\C-k$(...)\C-\M-e\r"' ») to replace the command line with a dynamic content. I.e., the macro first inserts a text « $(some-code-generator) » and expands it by C-M-e. Please note that $(some-code-generator) may want to include in a generated command characters that should be treated as shell special characters. If one wants to support a wide range of versions from Bash 3.2 (shipped with macOS) to the latest one, this is still one of the used techniques. If the behavior of C-M-e or shell-expand-line is going to be changed, such types of Bash configurations are all broken. For example, if $(some-code-generator) generates « echo "Hello, world!" », we have been expecting the output « Hello, world! ». If the quoting were going to be applied in the next version, the output would become « "Hello, world!" », which is not an expected behavior. If the requoting behavior would be desired, I strongly suggest keeping the existing behavior of shell-expand-line but adding a separate new bindable function (like shell-expand-and-requote-line) to perform the expansion and requoting. -- Koichi
