-
Notifications
You must be signed in to change notification settings - Fork 918
Better portability: build on Windows + Git Bash to run script/light.sh #2313
Comments
I'm not opposed to a PR for this... As long as everything still works! 😄 @LightTable/maintainers - any concerns or objections? |
@robjens while you are at it could you check bash on Windows Subsystem for Linux? |
No objections, as long as it works... and we are able to test that it does I'm good. |
Sounds like a PR for this would be appreciated @robjens - feel free to proceed if you so desire. |
Alright, will do... cheers. I'm not sure if I'm supposed to sign a CA but I'll check. Also I noticed it didn't work out of the box as expected when I changed the script pre-build but it might have also overwritten something so I'll take care to double check before I do a PR. |
No need for a CA from us! |
@sbauer322 Cool. I just built LT again on Windows and I changed the light.sh script before running build.sh for the first time. On compilation/setup finish, it tries to run script/light.sh at the very end right? It seems it may not be using the local one though, I'm guessing it uses the git cloned script ...? Since it basically notifies right after the git activity... If I try to run |
Oh, I believe the last |
Currently, the script/light.sh file ran after building this solution on a Windows machine, doesn't pick up the fact that I can actually run LightTable just fine (
Cannot detect a supported OS.
)At the moment, it checks first for Darwin - which I'd keep since it to has bash - but then proceeds to check
Linux
usinguname -s
as well, finally to check for Cygwin in the same fashion.Now, I am not sure if and why Cygwin would need to run the
.exe
executable but I presume this to be correct. However, in my case and sense, the following would have been a more reliable way to check:If Cygwin does in fact require the executable and somehow is incapable of running the shell file, it should come first. Else it could just the same code as above. It would run on any bash capable/installed shell under Windows.
Oh and note that
$(expr substr ...)
doesn't work here either, which is preventing it from finding out the system string to begin with. I guess, without any external commands, variable assignment and then built-in substring would be the 'cleanest' (which it isn't, use zsh for that) way:currsys=$(uname -s) && echo ${currsys:0:10}
Unfortunately, bash doesn't really allow for much subscripting so I don't think nested function, variable assignment and substring is possible in 1 go.For the record, my Git Bash reports
MINGW64_NT-10.0
which makes me inclined to think that whole string isn't really reliable but I guess one could work with theMINGW
bit.I wouldn't mind doing a PR but figured I should ask first if this would be a desirable change. The used snippet is the most idiomatic and portable way of checking I could think of.
The text was updated successfully, but these errors were encountered: