If just one of the range ends is negative, this now forces direction away from it.
I.e. if the beginning is negative, we go in reverse.
If the end is negative, we go forwards.
This fixes cases like
$var[2..-1]
if $var only has one element.
This just removes every invalid index.
That means with `set foo a b c` and the "show" function from tests/expand.in:
- `show $foo[-5..-1]` prints "3 a b c"
- `show $foo[-10..1]` prints "1 a"
- `show $foo[2..5]` prints "2 b c"
- `show $foo[1 3 7 2]` prints "3 a c b"
and similar for command substitutions.
Fixes#826.
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
GNU and BSD `mktemp` handle options differently, and it's a useful
utility for tests. As such, define a common `mktemp` function wrapper
for the test suite.
It might actually be nice to expand this for more flags and support it
globally, but that may result in confusion for any users of BSD mktemp
that expect to be running /bin/mktemp.
The span now properly points at the token that was invalid, rather than
the start of the slice.
Also fix the span for `()[1]` and `()[d]`, which were previously
reporting no source location at all.
When a variable is parsed as being empty, parse out the slice and
validate the indexes anyway, behaving for slicing purposes as if the
variable had a single empty value.
Besides providing errors when expected, this also fixes the following:
set -l foo
echo "$foo[1]"
This used to print "[1]", now it properly prints nothing.
Double expansions of variables had the following issues:
* `"$$foo"` threw an error no matter what the value of `$foo` was.
* `set -l foo ''; echo $$foo` threw an error because of the expansion of
`$foo` to `''`.
With this change, double expansion always works properly. When
double-expanding a multi-valued variable, in a double-quoted string the
first word of the inner expansion is used for the outer expansion, and
outside of a quoted string every word is used for the double-expansion
in each of the arguments.
> set -l foo bar baz
> set -l bar one two
> set -l baz three four
> echo "$$foo"
one two baz
> echo $$foo
one two three four
