Re: About `M-C-e` expand result `'` failed

[Koichi Murase]

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 <martin@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