I noticed while fixing issue #2702 that the fish program being tested
was sourcing config.fish files outside of the current build. This also
happens when Travis CI runs the tests but isn't an issue there because
of how Travis is configured to execute the tests.
I also noticed that running `make test` was polluting my personal fish
history; which will become a bigger problem if and when the fishd universal
var file is moved from $XDG_CONFIG_HOME to $XDG_DATA_HOME.
This change makes it possible for an individual to run the tests on
their local machine secure in the knowledge that only the config.fish and
related files from their git repository will be used and doing so won't
pollute their personal fish history.
Resolves#469
This isn't pretty, but it fails for, as far as I can see, no _real_
reason.
It doesn't seem to be possible to trigger the failure in real usage, no
matter how fast you press the ESC key followed by something else.
So now this is known and constant travis emails don't help it in any way.
Update the test runners so they set up their own environment in
test_util.fish. This simplifies the Makefile and paves the way for
adding utility functions for use in the tests themselves.
Also tweak colored output to reset before the newline instead of after,
so travis behaves better (for some reason reset causes travis to display
the line in black).
Split test_interactive off from test_fishscript and add a new target
test_high_level that tests both.
Add some Makefile magic so the tests can be run serially without using
sub-make, which gets rid of a little noise from the make output.
Rewrite interactive tests to look better.
As far as I know we can't access the build artifacts from Travis, so we
can't check the interactive logs after a test failure. Add an
environment variable that causes the test runner to dump the logs
itself, and set that variable for Travis.
