CDPATH fix, improved CLI help, updated URLs in read-me, cleaned up package.json

Makes sure that CDPATH isn't set, as it causes `cd` to behave unpredictably - notably, it can produce output, which breaks fullpath(). 

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

Thanks!

Mainly out of curiosity, was how did you come across the CDPATH
issue? This might be nice to put in the readme.

I have been considering removing `urchin -x`, at least for now,
as it is confusing to have two ways of doing the same thing.
The `urchin -x` approach feels a bit more shell-like and less
hacky to me, but that only works if it is actually works, and
I am not convinced at present that I have implemented it properly.

Your corrections to my typos introduced a new typo! (It's the
blog post link.) Otherwise, everything seems good at first glance;
I'll take a closer look this weekend and merge and whatnot.

Tom

On 03 Dec 10:21, Michael Klement wrote:
> > @@ -1,5 +1,9 @@
> >  #!/bin/sh
> >  
> > +# Make sure that CDPATH isn't set, as it causes `cd` to behave unpredictably - notably, it can produce output,
> > +# which breaks fullpath().
> > +unset CDPATH
> 
> Glad to hear it.
> 
> In general, the only way to affect the current shell's environment is by _directly sourcing_ a script. Any executable shell script (invoked as an executable) runs in a child shell that, even if it happens to be of the same type as the invoking shell, is isolated from it.
> 
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/tlevine/urchin/pull/14/files#r21252335