Multiple patches may be concatenated in the same patch file, such as git
commits which are changing multiple files at the same time. To handle
this, parse each patch in order in the patch file, and apply each patch
sequentially.
To determine whether we are at the end of a patch (and not just parsing
another hunk) the parser will look for a leading '@@ ' after every hunk.
If that is found, there is another hunk. Otherwise, we must be at the
end of this patch.
Previously patch would always expect the file that it was patching to
exist (even it were empty). If we know that the patch is creating a file
from nothing (i.e has a start line of '0'), then we treat a file that
doesn't exist as if it has no content lines.
Implement the patch '-p' / '--strip' option, which strips the given
number of leading components from filenames parsed in the patch header.
If not given this option defaults to the basename of that path.
The Test262RunnerHandler class in test-test262 was made in order to
spawn a subprocess, connect to its input/output error pipes, and obtain
its return value.
Later on, a copy of this implementation was added to TestSed with
modifications, such as adding support for reading from the output pipes
as well.
Unify these two implementations into a new Core::Command class. This new
implementation is more closely modeled from the TestSed implementation
due to the extra functionality it implemented.
While the tests for sed itself are simple to begin with, some
infrastructure was needed to make them simple.
Firstly, there was no home for tests for the applications under
Utilities, so I had to create a new subdirectory under Tests to host
them.
Secondly, and more importantly, there was previously no easy way to
launch an executable and easily feed it with data for its stdin, then
read its stdout/err and exit code. Looking around the repo I found that
the JS tests do a very similar thing though, so I decided to adapt that
solution for these tests, but with the higher purpose of someday moving
this new Process class to LibCore/Process, where the existing spawn
helpers are still very low level, and there is no representation of a
Process object that one can easily interact with.
Note that this Process implementation is very simple, offers limited
functionality, and it doesn't use the EventLoop, so it can break on long
inputs/outputs depending on the executable behavior.
