* Run integration tests on multiple shells
To make sure that I don't break tests for shells other than my
dev-box's `sh` and the `sh` on travis, each integration test case
now runs using `sh`, `dash`, and `bash.
Moves platform specific functionality into its own module.
Thanks to @Meralis40 for starting this!
This also gets just building on windows \^_^/
Although a lot of tests still fail (✖╭╮✖)
The `PlatformInterface` trait contains functions which abstract
over platform specific functionality, with implementations for
different platforms behind #[cfg(*)] attributes.
- `make_shebang_command()` constructs a command which will execute
the given script as if by a shebang. On linux this executes the
file, on windows it runs the interpreter directly.
- `set_execute_permission()` sets the execute permission on a
file. This is a nop on windows, since all files are executable.
- `signal_from_exit_status()` extracts the signal a process was
halted by from its exit status, if it was halted by a signal.
Mostly for debugging purposes, so I can make sure behavior is
consistent across different shells. Although I suppose this might
also be of use if you've got a mega weird `sh` that you'd like to
avoid.
Defaults to `sh` so current behavior is preserved.
- Unicode 9 defines emoji to be wide characters; before their
width was ambiguous. unicode-width has picked this up, so the
tests which expected emoji to be single-width have been updated.
- The ordering of the --quiet and --dry-run flags seems to be
have flipped in a clap error message, which broke a test, which
is unbroken by this commit
This is done for two reasons:
1. Such names cannot be given on the command line, since clap will
intercept them and wrongly interpret them as flags.
2. The name '---' can conflict with yaml document delimiters. Kind of
speculative, but I was thinking that it would be nice to make sure that
'---' and '...' are illegal in a justfile, so that that one can be
included in a yaml document stream. Is this silly? I am really not sure.
This is backwards incompatible, but I don't think anyone will notice,
since names that start with '-' are likely to be rare.
The recipe dependency resolver had a bug which caused it to not resolve
dependencies after the first.
This caused the parameter check later in the program to crash.
Added a test and fixed it.
Fixes#148.
If the first argument to just contains a `/`, then it will be handled
specially. Everything before the last `/` is treated as a directory, and
just will search for the justfile starting there, instead of in the
current directory.
Previously, only one recipe with parameters could be passed on the
command line. This was to avoid confusion in case the number of
parameters a recipe took changed, and wound up using as an argument was
was once a recipe.
However, I don't think this is actually particularly confusing in
practice, and could be a slightly annoying limitation.
Now, any number of recipes with parameters may be given on the command
line.
Fixes#70
Recipes may now have a final variadic parameter:
```make
foo bar+:
@echo {{bar}}
```
Variadic parameters accept one or more arguments, and expand to a string containing those arguments separated by spaces:
```sh
$ just foo a b c d e
a b c d e
```
I elected to accept one or more arguments instead of zero or more arguments since unexpectedly empty arguments can sometimes be dangerous.
```make
clean dir:
rm -rf {{dir}}/bin
```
If `dir` is empty in the above recipe, you'll delete `/bin`, which is probably not what was intended.
The grammar now permits blank lines in recipes.
Note that inside of recipes, the token `NEWLINE` is used instead of the
non-terminal `eol`. This is because an `eol` optionally includes a
comment, whereas inside recipes bodies comments get no special
treatment.
Blank lines were being ignored by the parser, so lines would be reported
incorrectly in error messages from shebang recipes. Blank lines are now
included by the parser, so shebang recipes expand to have the non-blank
lines in the expected place in the file.
Causes all recipe lines to be printed, regardless of --quiet or `@`.
Prints the name of each recipe before running it. Hopefully useful for
diagnosing problems.
An invocation like `just foo=bar` would lead to no recipe being run due
to the way that override arguments were being processed.
Fix that and add a test that covers that case.
