First of all, I'd like to direct your attention back to the original email in this thread, by A4-Tacks: https://lists.gnu.org/archive/html/bug-bash/2024-01/msg00132.html That looks a lot more like a bug, and I'm sorry I distracted from it with my statement questioning what shell-expand-line was doing in the more general case.
On Fri, Feb 2, 2024 at 1:26 PM Chet Ramey <chet.ra...@case.edu> wrote: > Are you then suggesting a bindable readline function to quote the line > or region? It's not reasonable to change a function that has worked one > way for 30+ years. > Ultimately, what I'm saying is that a different bindable function that performs all the shell expansions other than quote removal would be more useful than shell-expand-line. As much as Mike Jonkmans didn't address this in his email just now, that's what I see in this exchange, as well: On Fri, Feb 2, 2024 at 10:10 AM Chet Ramey <chet.ra...@case.edu> wrote: > On 2/2/24 8:12 AM, Mike Jonkmans wrote: > > I might expect that, because it would be useful to see what is going to > be > > executed. > > I don't get this part. A desire is not an expectation. Not performing quote removal - or potentially adding backslashes - would be more desirable. What we have in shell-expand-line seems like what the user wanted, but not quite. shell-expand-line didn't make a ton of sense 30+ years ago, either, but I won't argue that its behavior should be changed, considering that performing quote removal was apparently what was intended. I don't even use bindable functions, really. A4-Tacks's original email just got me curious as to what you would even do with the result if the bug he encountered wasn't present. I finally look in that part of the manual, and now I'm trying to remember C-x C-e, because edit-and-execute-command would be really useful to me. I wasn't aware of an undo function, either, for that matter. That function makes a lot of what I'm saying here moot, anyway.
