Filenames provided by fs.ls already use slashes instead of backslashes so the replace(fromDir, toDir) does nothing and the file is truncated. (Issue #190)
This was causing it to mis-calculate the paths, and end up losing the
output directory entirely, and overwrite the template static files
with themselves, resulting in truncation to zero-length. Of course,
they were also missing in the output.
It was expecting to be able to split paths on
System.getProperty("path.separator"), but that describes how to put a
path together, not how to take one apart, which is more complicated.
In particular, in windows, / is as valid a separator as \ in all but a
few UI contexts.
And since we need to pass / in paths that may get turned into URI's,
it's important to handle this correctly.
Java already provides a File facility to handle these sorts of operations.
This patch makes use of java.io.File to:
1) Find the parent of a File for dirname.
2) Find the name of a File for basename.
It also now makes use of substring for removing the ext for basename,
rather than Array.prototype.slice + join(""). I'm not sure what that
was all about... It does have the effect of ensuring it's a Javascript
String, but calling String() has the same benefit and is much more clear.
You can put that back if there was a reason for it, but it looks just
confused to me.
Under Cygwin, we need to be a bit more aggressive with replacing \ with /
to avoid \ in URIs internally. This shows up when running the tests with -T,
but not when running files directly, for reasons I don't fully understand.
This patch replaces the previous replacement of \ => / with one that happens
earlier and applies to all references, not just the URIs we construct.
Cygwin now passes jsdoc -T from any directory.
On MinGW and Cygwin, we have different representations for pathnames,
neither of which Rhino understands. We also have to contend with '\',
which is not a legal URI character.
And we have to supply a third / after file:// (two before the null
hostname, and one before the start of the absolute path). Since Windows
paths don't start with /, we have to supply it in that case.
We handle the MinGW and Cygwin cases by asking for the information with
'pwd -W' for MinGW and 'cygpath $(pwd)' for Cygwin, before finally
falling back to pwd for everyone else. Then, if they don't start with '/'
we supply the extra '/' for the URL.
@partial Possibly this should be a core tag, but I think some time in the plugin incubator will be very useful, as a way to test it out and see how suitable it is for core. Thank you for contributing.
