Open wfleming opened 8 years ago
@mrb are you still interested in maintaining this linter? There are a few issues that haven't gotten any responses here and I have no experience with this myself to help out.
(Plus my main machines are Windows, and this issue shows many of the reasons I haven't done anything with this...)
@Arcanemagus Hi there! We are maintaining this linter, yes. I don't have access to a Windows machine, currently, so that makes this bit a little challenging. Do you have the time/inclination to work through any of these bugs?
Ah, I see you are both in the Code Climate group :stuck_out_tongue:
I can try to get this setup on my laptop at home tonight and see what I can do.
@Arcanemagus Yep, we're coworkes :smile: - that would be fabulous!
Currently the plugin presumes in several places that it is running in a *nix environment, and does not operate correctly on Windows. This issue details several known places where work probably needs to be done.
It should be noted that the new "bash for Windows" support that's been announced could potentially solve this problem with minimal changes (though some changes would still be required, I think). That would also add another installation dependency, though, so may not be the correct choice.
Current places needing thinking:
< /dev/null
should not be appended the command to be run.This isn't valid Windows command syntax, of course. I'm not sure why it's needed on Linux, either, actually: our CLI doesn't use stdin. It might be related to the fact that the plugin invokes
bash
with-l
, but I think there's a more correct way to get the desired effect.Paths sent to the CLI need to be Unix-ized
Paths relativized from Atom are, of course, Windows paths (e.g.
lib\foo\thing.rb
). They need to be converted tolib/foo/thing.rb
to be properly handled by the CLI, since the CLI itself is running in a Linux environment and the files are mapped into that Linux environment.Note that the reverse mapping probably needs to be handled when parsing the JSON results from the CLI.
Don't depend on bash
I believe this is being done on *nix systems to pick up potential changes to ENV for docker-machine, etc? If so, we might need to extract this into a function & decide the full command conditionally based on OS.
There may be other snags. The above is just what I've identified at the moment.