Ihor Radchenko <yantar92@posteo.net> writes:

> There could be multiple such blocks in the script. And it may not be
> bash, but something else (fish, csh, posh, etc). Finding ways to do the
> wrapping for all the shell flavours will be maintenance hell.

Well we already have something like this in org-babel-sh-eoe-indicator.
Having similar variables for ob-fish.el, ob-csh.el and others doesn't
really sound like too much trouble for me, you'd need something like

(defvar org-babel-sh-boe-indicator "if true; then echo org_babel_sh_boe\n")
(defvar org-babel-sh-eoe-indicator "\necho org_babel_sh_eoe; fi")
(defvar org-babel-sh-boe-output "org_babel_sh_boe")
(defvar org-babel-sh-eoe-output "org_babel_sh_eoe")

and similar for other ob-*.el's. Though, thinking about this more, for
the case of ob-python.el, where indentation matters, it does indeed
sound like trouble. In addition to pre-pending an "if True:", we'd also
have to indent the subsequent lines.

> So, I'd prefer comint-based solution.
> Such solution may also benefit other comint uses beyond this specific
> issue with Org.

>> Or maybe inject something like 'oldps=$PS2; PS2=""' before the command
>> and 'PS2=$oldps' after the command. But whether this works could depend
>> on the shell, some shells might have something like $PS3 or $RPS1, for
>> example.

> But will accept-process-output correctly work with PS2=""?

Looking at the code in ob-shell.el, it probably wouldn't just work if
you were to prepend your command with PS2="". You'd probably have to
move accept-process-output at the end outside of the loop. (Inside the
loop, accept-process-output could wait forever, since the process
wouldn't print anything, PS2="" after all.)