2847b020b4
Also: Improved CLI help, updated URLs in read-me, cleaned up package.json:
I've tried to clarify the intent of `-x` in the CLI help, but I haven't touched the read-me in that respect.
I don't see any benefit to `-x`:
* Just using `#/bin/sh` as the shebang line in combination with `-s <shell>` gives you the same functionality,
* When it comes to invoking scripts from _within_ test scripts, nothing can do the work for you: you consciously have to mark the invocation with _something_ to indicate that it should be controlled from the outside; it won't get any easier than `$TEST_SHELL ...`
* Finally, using a shebang line such as `#!/usr/bin/env urchin -x` is problematic for two reasons:
* Some platforms can handle only *1* argument in a shebang line.
* In a _package-local_ installation, `#!/usr/bin/env` may not find the Urchin executable.
I'm also not sure how the following (from `readme.md`) fits in the picture:
> It might make sense if you do this.
export TEST_SHELL=zsh && urchin -x
export TEST_SHELL=bash && urchin -x
(As an aside: To achieve the same thing, you don't need `export`; `TEST_SHELL=zsh urchin -x` and `TEST_SHELL=bash urchin -x` is the better choice.)
How does this relate to use in a _shebang line_?
`urchin_help()` now uses a here-doc: easier to maintain, and should work in all Bourne-like shells.
`readmeFilename` removed from `package.json`:
> "The readmeFilename does not need to ever be in your actual package.json file" - npm/npm#3573
7 lines
85 B
Bash
Executable File
7 lines
85 B
Bash
Executable File
#!/bin/sh
|
|
|
|
cd ..
|
|
export CDPATH=$PWD
|
|
./urchin -f 'tests/urchin exit code' >/dev/null
|
|
|