multi-line string command continuation behavior

[travisdowns]

First, thanks of all for ble.sh. I came to ble.sh primarily to integrate with atuin, which needs a pre/post hook which ble provides, but I've also come to like some of the other functionality ble provides.

My question/issue is how to (optionally, i.e., via config) get ble.sh multi-line edits to work more like vanilla bash. Specifically, when using coding agents, the agents expect to insert multi-line strings without any continuation character like:

echo "hello
world"

and have it work (this works in vanilla bash). In my ble.sh I instead get bash: unexpected EOF while looking for matching "' after the first line, and then the second line world" will be sent separately with another error.

Can I get the default bash behavior here?

Here

$ ble summary

GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu) [Ubuntu 24.04.3 LTS]
ble.sh, version 0.4.0-devel4+14f98dd (noarch) [git 2.43.0, GNU Make 4.3, GNU Awk 5.2.1, API 3.2, PMA Avon 8-g1, (GNU MPFR 4.2.1, GNU MP 6.3.0)]
bash-completion, version 2.11 (hash:9abb523dbcb688e7fae4b87f5fc9d155b658d9ba, 76898 bytes) (noarch)
fzf key-bindings, (hash:c4dce3ba5bfafecbc6c47695f89ef02c305b984e, 5524 bytes) (noarch) (integration: off)
WARNING: fzf integration "integration/fzf-key-bindings" is not activated.
atuin, version 18.5.0 (/home/tdowns/.atuin/bin/atuin)
locale: LANG=en_US.UTF-8
terminal: TERM=xterm-256color wcwidth=15.0-west/16.0-2+ri, vte:7600 (61;7600;1)
options: +extglob +histappend -hostcomplete +inherit_errexit

The condensed version of my .blerc:

bleopt complete_auto_complete=
function blerc/emacs-load-hook {
  ble-bind -f 'C-m' accept-line
  ble-bind -f 'RET' accept-line
  return 0
}
blehook/eval-after-load keymap_emacs blerc/emacs-load-hook
function blerc/vim-load-hook {
  ((_ble_bash>=40300)) && builtin bind 'set keyseq-timeout 1'
}
blehook/eval-after-load keymap_vi blerc/vim-load-hook

[akinomyoga]

The condensed version of my .blerc:

...

  ble-bind -f 'C-m' accept-line
  ble-bind -f 'RET' accept-line

...

These key bindings should be the primary culprit. Could you remove these bindings and see if the problem is solved?

If the problem isn't solved by removing these, that implies your AI agent sends \n instead of \r for newline, which is not common in the terminal input stream. If it is the case, I'll explain a workaround in a reply.

[travisdowns]

Thanks for the speed reply!

These key bindings should be the primary culprit. Could you remove these bindings and see if the problem is solved?

The problem is worse if you remove ble-bind -f 'RET' accept-line, since then you will just stay in multi-line mode, waiting for C-j to be pushed (which agents do not expect). From the PoV of the agent the command has simply hung.

So this was my attempt to make it work a bit more like vanilla bash, but I guess I cannot have both?

Probably it is easier to simply disable ble.sh in terminals used by agents (not sure if there is an env var for that, I can just do it at the .bashrc level level if not).

[akinomyoga]

The problem is worse if you remove ble-bind -f 'RET' accept-line, since then you will just stay in multi-line mode, waiting for C-j to be pushed (which agents do not expect).

Hmm, then it implies that the AI agent doesn't use \n (C-j) to represent the newline. I don't have an idea about what's happening, so I don't know the solution based on the current information. I'd like to know what exactly the AI agent sends. Could you follow the following steps to get the information?

1. In a Bash session, run the following command

$ ble/debug/keylog#start

2. In the same Bash session, let the AI agent send multi-line commands. This is supposed to cause the error you reported, but that's fine for now (because we just want to see what the AI agent sends in the input stream to ble.sh).
3. If garbage command line contents remain, please erase it. In the emacs editing mode, you can press C-c.
4. Run the following command. Then, a summary of the input stream since ble/debug/keylog#start should be printed. Could you provide the summary contents here?

$ ble/debug/keylog#end 

[travisdowns]

Hmm, then it implies that the AI agent doesn't use \n (C-j) to represent the newline. I don't have an idea about what's happening, so I don't know the solution based on the current information. I'd like to know what exactly the AI agent sends. Could you follow the following steps to get the information?

I am confused, I am quite sure the AI agent sends \n and in any case the behavior is reproducible without any agent.

In the default ble.sh, once you enter multi-line mode, you only get out of it via C-j, right? Hitting "Enter" (sending \n) doesn't leave multi-line mode, it just adds more blank lines to the existing multi-line buffer. At least that's the behavior I observe.

I didn't do the test of what you mentioned yet since clearing up the above comes first I think.

[akinomyoga]

I am confused, I am quite sure the AI agent sends \n and in any case the behavior is reproducible without any agent.

In the default ble.sh, once you enter multi-line mode, you only get out of it via C-j, right?

In the terminal protocol in the input stream, \n is equivalent to C-j. Both are transmitted as byte \x0A.

Hitting "Enter" (sending \n)

No, hitting Enter doesn't send \n. It sends the byte \x0D (which is equivalent to \r and C-m).

I didn't do the test of what you mentioned yet since clearing up the above comes first I think.

Could you please do the test?

[travisdowns]

In the terminal protocol in the input stream, \n is equivalent to C-j. Both are transmitted as byte \x0A.

Hitting "Enter" (sending \n)

No, hitting Enter doesn't send \n. It sends the byte \x0D (which is equivalent to \r and C-m).

Thank you for the clarification.

Could you please do the test?

I did the test. Here's a screenshot:

Here's the text version, copy/pasted from the terminal:

tdowns@p16:~/scrap/ble-test$ ble/debug/keylog#start
tdowns@p16:~/scrap/ble-test$ echo "hello
world"

hello
world
tdowns@p16:~/scrap/ble-test$ echo hi
hi
tdowns@p16:~/scrap/ble-test$ ble/debug/keylog#end 
===== bytes =====
101 99 104 111 32 34 104 101 108 108 111
 13 119 111 114 108 100 34 13 10 101 99 
104 111 32 104 105 13 192 155 91 50 48 4
8 126 98 108 101 47 100 101 98 117 103 4
7 107 101 121 108 111 103 35 101 110 100
 32 192 155 91 50 48 49 126 13

===== chars =====
e c h o SP " h e l l o RET w o r l d " R
ET LF e c h o SP h i RET ESC [ 2 0 0 ~ b
 l e / d e b u g / k e y l o g # e n d S
P ESC [ 2 0 1 ~ RET

===== keys =====
e c h o SP " h e l l o C-m w o r l d " C
-m C-j e ac_enter c h o SP SP ac_enter h
 h ac_enter i C-m C-m paste_begin C-m

To clarify, the command

echo "hello
world"

was inserted by the AI on my question. It "hung" as descirbed above (not shown above), like so:

So I hit C-j myself to run it. The echo hi was typed myself.

As I mentioned, none of this is agent specific: the behavior is identical if you just copy-paste these commands from the clipboard. If you copy:

echo "hello
world"

into a ble.sh shell, it does not execute but stays in the multi-line editor as described. I believe this is a feature of ble.sh and not surprising?

[akinomyoga]

was inserted by the AI on my question. It "hung" as descirbed above (not shown above), like so:

[image]

Ah, OK. So the originally reported problem of bash: unexpected EOF while looking for matching `"' is actually solved by removing the keybindings to C-m and RET. Then, the behavior is understandable. Since the AI agent is confirmed to send \r for newlines as expected by the terminal protocol, one solution is to specify the syntax option to the widget accept-line.

...

function blerc/emacs-load-hook {
  ble-bind -f 'C-m' 'accept-line syntax'
  ble-bind -f 'RET' 'accept-line syntax'
  return 0
}

...

[travisdowns]

Ah, OK. So the originally reported problem of bash: unexpected EOF while looking for matching `"' is actually solved by removing the keybindings to C-m and RET. Then, the behavior is understandable.

Yes exactly. I should have been clearer in the original report: I had issues whether I added the custom bindings or not, just the syptoms where different (with default bindings the problem is that the command is not executed).

one solution is to specify the syntax option to the widget accept-line.

Ah, I wasn't aware of this, I will try it! This sends the command when the command is valid, e.g., closing parens, quotes, etc, have all been closed, like vanilla bash? That sounds just right (and actually what I've been looking for).

[travisdowns]

Based on my initial testing accept-line syntax approach is working smoothly!