can not run jx login on Windows

[agentgonzo]

Summary

when I run jx login --url I can log in but the core web (chrome) window stays running and the cli never returns.

If I exit chrome after 5 minutes or more I get

error: logging into the CloudBees application: shutting down Chrome: Get http://127.0.0.1:9222/json/list: dial tcp 127.0.0.1:9222: connectex: No connection could be made because the target machine actively refused it.```


### Steps to reproduce the behavior
run `jx login --url <some core url>` on windows

### Jx version

The output of `jx version` is:

NAME VERSION
jx �[32m1.3.661�[0m
jenkins x platform �[32m0.0.3061�[0m
Kubernetes cluster �[32mv1.9.7-gke.11�[0m
kubectl �[32mv1.10.3�[0m
helm client �[32mv2.11.0+g2e55dbe�[0m
helm server �[32mv2.11.0+g2e55dbe�[0m
git �[32mgit version 2.15.1.windows.2�[0m
Operating System �[32mWindows 10 Pro 1809 build 17763�[0m

### Kubernetes cluster

What kind of Kubernetes cluster are you using & how did you create it?
GKE

### Operating system / Environment
Windows

### Expected behavior
It should work

### Actual behavior
It doesn't. See above

[agentgonzo]

/cc @jtnord

[fiunchinho]

Same behaviour in Mac OSX (mojave) using Chrome.

jx version
Failed to find helm installs: failed to run 'helm list' command in directory '', output: 'Error: incompatible versions client[v2.12.1] server[v2.11.0]': exit status 1
NAME               VERSION
jx                 1.3.684
Kubernetes cluster v1.11.5-gke.4
kubectl            v1.13.1
helm client        v2.12.1+g02a47c7
helm server        v2.11.0+g2e55dbe
git                git version 2.20.1
Operating System   Mac OS X 10.14.1 build 18B75

[jtnord]

someone has changed something - allthough it still fails but now it fails earlier and in a much more sinister way..

jx login --url=redacted
error: logging into the CloudBees application: creating the chrome user data dir: FindFirstFile /tmp: The system cannot find the file specified.

[jtnord]

hardly suprising that it fails like this - but I have no Idea why the failure is obvious now and not before

[jtnord]

Not sure if this really is a windows issue, but it seems like the tail fails (without error) due to a timing issue.
My guess is that if the profile directory / file does not exist as Chrome is still starting up by the time the tail is invoked then it will not see any changes when the file is created due to the follow argument not working.

Assumption has been sunwhat validated by adding a big fat sleep on this line

[jtnord]

assumption was incorrect, the sleep just meant that the file had lots of lines when it was tailed, actual cause was relying on io-notify which is not available on all platforms / file systems.