Split bash commands by the new line character

[tofarr]

End-user friendly description of the problem this fixes or functionality that this introduces

• Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below

---

When a bash command spans multiple lines the output is really confusing - so we split each command by the newline character for better readability. My initial approach was to split the command into multiple separate commands and add these to the event stream individually, but this did not play well with the LLM - The behavior was non-deterministic, but sometimes it would basically say "Thank you for running the first command - what about the others?" And it would supply the commands that had not yet been run to be run again, resulting in duplicates in the stream!

So my approach was to improve the output from splitting commands in the runtime client, while still treating these as a single RunCmdAction

Example 1:

Print the word "OpenHands" in the bash console in ascii art. Use only the echo command to do this. New lines of text should use the same invocation of the echo command

Example 2

Please run the following commands all at once:

* ls -lah
* echo "May the force be with you!"
* echo "May the odds be ever in your favor!"
* echo "Live long and prosper!"

Example 3

Please run the following commands all at once:

* ls -lah
* echo "hello world"
* echo a sample kubernetes deployment yaml into deploy.yaml

(This looks a little uglier because the console interprets each tab as 8 spaces.)

Example 4 (With confirmation mode!)

Please do the following in a single bash command:

* sleep for 5 seconds
* print "You must Narfle the Garthok!"
* Print the current working directory

Example 5 (Running user commands)

[xingyaoww]

We actually something like this on the backend - what do you feel if we move them to the controller here? That is, we break one CmdRunAction to multiple ones and send them over for execution in agent controller?

OpenHands/openhands/runtime/client/client.py

Lines 433 to 437 in ec3152b

	commands = split_bash_commands(action.command)
	all_output = ''
	for command in commands:
	if command == '':
	output, exit_code = self._continue_bash(

[enyst]

This is an interesting idea, how will it work with longer running commands though? Here _pending_action is set. When the first new action is executed the runtime will put an obs in the stream which will make it unset here... this places them in the stream and continues looping here. Then the step would pass here before all are executed, no? What prevents it?

[rbren]

Yeah this probably messes with _pending_action quite a bit....

@tofarr you can probably test this by asking the agent something like:

Please run echo hello and ls -lah in the same <execute_bash> block

[enyst]

I kept thinking about this PR since the other day, for some odd reason. I'd appreciate if we take some time to make sure this could work. It seems to me it won't work right or I just don't see why it would.

For added fun, let's take a delegates' case: if the action is split in 5 in a delegate controller, and mini-action 1 of 5 has an error, then... okay, I think something else is bugged currently, but even with a fix, say like this, the delegate ends here. In this PR, is it possible to have obs 2-5 arrive in the stream after the delegate ends? If not, can you please point out what would prevent it?

Because it seems like the child obs could end up in the parent's history, which is a tad messy. 😅

[rbren]

what's this about?

[tofarr]

This was from the original prompt:
.. Each instance should have a blank 'thought' attribute, except for the last one which should have the thought from the original action...

The reason for this is that it prevents the frontend UI from printing the thought multiple times. e.g.: (Without this functionality):

[enyst]

It is possible that the action includes several times the same bash command, right? Like echo *, I don't know.

I wonder what would happen here. If they're separate in the stream, like mini-action 1, mini-obs 1, mini-action 2... it seems like they can be detected as repeated actions / obs, and the agent should stop with stuck in a loop error. 🤔 We do this for some cases when the LLM gets trapped and responds with the same thing over and over.

[rbren]

It is possible that the action includes several times the same bash command, right? Like echo *, I don't know.

Yeah this is possible, but I can't imagine a scenario where the agent would want to do this :)

[rbren]

So this seems to work on the backend, but the frontend isn't splitting things up correctly

here's my sample prompt:

please run the following commands all at once:

* ls -lah
* echo "hello world"
* echo a sample kubernetes deployment yaml into deploy.yaml

it seems like we get all the CommandRunActions first, then we get all the Observations. Instead, we should get them collated properly

[rbren]

also notice the mangled YAML content on the last command there--not sure what the issue could be...

[tofarr]

The command posted by @rbren seems to be working now - though the bash console seems to turn tabs into 8 spaces, which makes it hard to read:

[tofarr]

Confirmation mode is now behaving appropriately too:

[rbren]

@tofarr looks like it's still not working right based on your screenshot. The console in the UI should show

$ ls -lah
./foo
./bar
$ echo "hello world"
hello world

etc. I.e. we should see the output of one command before the start of the next

[tofarr]

Commands are only outputted on completion

[rbren]

is there a better name for this?

[enyst]

Perhaps location, or loc, or current_dir?

[tofarr]

I renamed it to interpreter_details

[rbren]

@enyst we went with a very different implementation here if you wouldn't mind taking another look and unblocking

@xingyaoww would like your approval here as well

Enysts comments were valid and have been addressed in subsequent edits. We no longer split the commands in the way that was worrisome

[enyst]

I agree my concerns were addressed.