waitid() *may* be called many times if a job does not exit, so only
assert this fact when the job has in fact exited.
Also allows Background nodes to contain non-execute nodes.
This allows us to easily re-use history loading and saving in other
programs using Line::Editor, as well as implementing universally
recognized HISTCONTROL.
In the future all (normal) output should be written by any of the
following functions:
out (currently called new_out)
outln
dbg (currently called new_dbg)
dbgln
warn (currently called new_warn)
warnln
However, there are still a ton of uses of the old out/warn/dbg in the
code base so the new functions are called new_out/new_warn/new_dbg. I am
going to rename them as soon as all the other usages are gone (this
might take a while.)
I also added raw_out/raw_dbg/raw_warn which don't do any escaping,
this should be useful if no formatting is required and if the input
contains tons of curly braces. (I am not entirely sure if this function
will stay, but I am adding it for now.)
Theoretically, this assertion should never trip (at least, on serenity
where we don't really reuse PIDs).
This change should be considered temporary, until we figure out whether
waitpid() is being called twice (and succeeding) for one given PID.
This really just works around the core issue, which is that we have no
reliable way to know exactly who raised the signal (yet).
Fixes#3645, in a very weird (yet apparently standard) way.
The following example should illustrate one issue arising from this:
$ echo 'exit 1' > example.sh
$ Shell example.sh
Good-bye!
This message is meant to be shown to an interactive user, but not in a
shell script.
This fixes a duplicate message when running `jobs` for the first time
after a job has been moved to the background.
Also actually announces background exits now :^)
This patchset makes the shell capable of lazily resolving and executing
sequences of commands, to allow for putting logical sequences in the
background.
In particular, it enables And/Or/Sequence nodes to be run in the background,
and consequently unmarks them as `would_execute`.
Doing so also fixes job control to an extent, as jobs are now capable of
having 'tails', so sequences can be put in the background while
preserving their following sequences.
Fixes the problem reported in #3073. While trying to write a test
for this, I thought I'd use
Shell -c 'for i in $(seq 100) { echo $i }' | head -n 1
but that makes the cpu spin at 100% and doesn't terminate even
with this fix here. But at least piping disasm into head now works.
