busterjs/buster — Issue #125: Win compat: make bin/buster work on Windows
Author: meisl
Created: 2012-03-08 20:26:15+00:00
State: open

**Setup:**
- WinXP Pro SP3 32bit, node 0.6.11 via .msi installer, npm is 1.1.1 (came with the .msi)
- buster 0.4.5 beta2 installed via npm with a few hacks by hand to get it going:
- alongside buster/: [pre-built contextify](https://github.com/downloads/Benvie/contextify/contextify-0.1.1-node0.6-win32.zip) (ATTENTION: needs some more, not to be used as-is)
- watch-tree installed via npm into buster/node_modules (used by buster-autotest, missing from deps) - yet this is *defunct on Win*
- trying to ``buster test`` with ``buster.js`` config file.

**Problem:**
@augustl, with foresight, already has [rewritten the former buster shell script as js so "it [will be] portable to Win32"](https://github.com/busterjs/buster/commit/57b175ec1ba0a72cac48bef95195cd90c8c26156#bin/buster) time ago.
However, prior to my investigations, it wouldn't give me *anything*, not even my prompt back (except for trivial cases); for convenience: [bin/buster, current state](https://github.com/busterjs/buster/blob/master/bin/buster).
Well, as things happen, I first stumbled upon this:
```
if (argv.length == 0 || argv[0] == "--help" || argv[0] == "-h") {
/* ... */
} else {
var cmd = argv.shift();
/* ... */
runBusterCmd(cmd);
/* ... */
}
```
on top level where there also is the function ``runBusterCmd`` that's called:
```
function runBusterCmd() {
childProcess.exec(
"command -v buster-" + cmd,
/* ... */
```
Spotted it? No formal parameter ``cmd`` declared but used in first arg to ``exec``. Well, turns out that's not the real problem but it makes for a nice **price question**:

- *Why (the hell) is the value of ``cmd`` nevertheless the first cli arg proper within ``runBusterCmd``?!*
Bug in node? (no). "Bug" in javascript itself? (well, debatable...).

The answer is more intricate than one might expect, and IMHO it calls for a (style) rule to be followed:
*Always put variable declarations at the **beginning of the scope**!*
Of course, for that to comply with you'll have to know where the scope's beginning really is...

Anyways, the **real problem on Win is the use of ``command -v``**, and the reason why it took me so long to realize is that there is indeed a ``command`` on Win but with quite different semantics than the POSIX ``command``. AFAIK the POSIX ``command -v foo bar`` only serves to restrict where to search for ``foo``, otherwise has the same affect as just ``foo bar``.
On Win, however, it spawns another cli, with its own stdout and stderr...

**Workaround:**
quite simple: just ``exec("buster-" + cmd)``, i.e. drop ``command -v `` entirely. However, I'm no Unix guru so I'm not sure if that's really clean and/or what is intended.

**Note:**
Beware, this is only the tip of the iceberg, at least in my experience. Don't expect to have buster (the package) work with just this fixed. I'm wading through the src right now, with glob as the current "favourite suspect" (nasty Win "\" vs. "/"). And I'm still working on getting a git clone working (somehow) on Win, as opposed to npm install with hacks.
But that's another issue. I'll keep 'em coming :)

**p.s.:** seem's I'm too dumb to make good use of the "Flavoured Markdown". Can anybody please tell how to get proper indentation and maybe even syntax-highlighting? [docs](http://github.github.com/github-flavored-markdown) allude that it should be possible...