seba@KORCLT29912:~$ curl https://install.meteor.com/ | sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 7592 0 7592 0 0 18983 0 --:--:-- --:--:-- --:--:-- 19027
Downloading Meteor distribution
curl: (22) The requested URL returned error: 403 Forbidden
Retrying download in 5 seconds...
Okay, so after manually changing the install script for now, I got meteor installed and running on bash for windows.
Sadly, it is pretty useless.
What works is creating and running a meteor project on the linux file system (e.g. your linux home directory). But that’s pretty useless, since you can’t open it in any GUI. So this is only for the vim people among us.
Running a meteor project on the windows file system from the ubuntu bash (e.g. under /mnt/c/...) does not work, since mongo can not start. You get:
Unexpected mongo exit code 100. Restarting.
Unexpected mongo exit code 100. Restarting.
Unexpected mongo exit code 100. Restarting.
Unexpected mongo exit code 100. Restarting.
Can't start Mongo server.
MongoDB had an unspecified uncaught exception.
This can be caused by MongoDB being unable to write to a local database.
Check that you have permissions to write to .meteor/local. MongoDB does
not support filesystems like NFS that do not allow file locking.
Too bad, I really hoped this could work.
I might try to see if I can install X server and open GUI applications that way, like you would do with a remote terminal session.
So, it looks like if a Meteor project has the MongoDB originally built on Windows it runs properly. However, if you build/reset the project with bash, Mongo becomes unable to start. According to the warning messages I mentioned in my post, this might be related to the MongoDB engine being used. Mongo engines are beyond my scope of knowledge, but I’ll leave the hanging thread here if anyone wants to follow it.
In the meanwhile, bash is quite useful in my specific use case - faster code refresh and bash command sweetness on a previously existing project built on Windows.
Oh okay. I’ll leave it up to the moderators to merge the threads and continue here for the time being.
Problem is that I’m mainly experiencing very slow rebuild times because of AV-software which is corporate regulated (I can’t turn it off). I hoped using the linux file system would do away with this problem. But it seems I still need to use the windows file system.
With 20 years in dev I know the feeling and it will not change apart from that down the road it will be entire languages and platforms you’ve put years into, that will be made redundant and you have learn new stuff. But I wouldn’t have it any other way. It’s progress and that’s good. Old timer out.
Many existing Meteor projects from Windows seem to run fine on Ubuntu Bash after cloning them into the linux file system, e.g. /home/… So, to still use our favorite editor on Windows, every time we hit save, we could sync the changed project file from Windows filesystem to a folder on the linux filesystem, couldn’t we?
Tried it manually at least with rsync (and tmux) and it works as expected: meteor recognizes the changes as usual and processes them. Next step is to automate the syncing or let rsync check for changes in a short intervall.
Did anybody tried this stuff, too? What do you think?
I’m not sure I understood you correctly, but if I did I think you are seriously over complicating it. You do not need to clone meteor into the linux file system, as Bash is able to access the windows file system (at /mnt/c). My use case is exactly what you said - favourite editor on Windows and running meteor on Ubuntu Bash, meteor detects code changes, Chrome on Windows reloads.
I’m really not sure how you guys are running your Meteor projects directly under the /mnt/c directory.
Because that particular mount is a linked NTFS filesystem which really doesn’t like file-locks / symlinks (at least the way *nix does it). Every time I tried to use that directory, Meteor would crash and burn.
@sashko After trying to use bash on windows with meteor for a while, I can tell you it isn’t ready for day to day development. Still a lot of weird issues with mounting the files, symlinks, git, and even using an editor that’s installed outside of bash.
For now, I really appreciate all the work you put into the windows version
Even if the meteor tool were to work perfectly inside bash for Windows, where should the project be located and how should the editor access it?
That is, should we keep the project inside the emulated Linux filesystem, or in the regular Windows filesystem under /mnt/c? I’d be incredibly surprised if the Linux file-watching API somehow worked and detected file updates on Windows through the emulation layer. Has anyone tried this?
I’ve tried it both ways and I can’t get either to work. The permissions always end up broken, the file watching for auto reload falls apart, and the two operating systems fight with each other trying to reformat tabs and spaces constantly which destroys you commits on git. You even get bizarre errors where each OS will see different versions of the file depending upon which edited it last.
I tried for about a day to get it to work, but I never got it to a point where it was stable enough for me. It just isn’t ready for professional development yet. I have no doubt that if they keep working on it will be really useful in the future if they can iron out the current issues. Bash on Windows has amazing potential!
Oh, it does work. You just have not to be afraid of symlinks.
The easiest way to go at it is using Git (or some other kind of repository).
You first clone your repo into a folder in Windows (like C:\Users\username\documents) and then do the same inside Bash (Do a cd ~ first, though, because otherwise you won’t be in your home folder).
Then you symlink almost everything from Bash to the Windows repo like thus:
VERY IMPORTANT: The ln -s must NOT have a trailing slash. There’s a bug with the UbuntuOnWindows implementation which creates an infinite recursion if you create a symlink to a directory if the target directory’s path has a trailing slash.
Basically, you symlink everything except the /.meteor/local and /node_modules/ folders.
If you did everything right it should then look like this:
@rhywden oh nice, glad you figure it out! I was not using symlinks the way you were so that probably what I was missing. I’ll give it a second change when I have a minute.
It’s good that you got that to work, but it’s kind of insane to have to do that for every meteor app I want to develop.
How does the file watching work in that case anyway? The Linux file-watching API goes through the symlinks and somehow manages to function properly in the Windows filesystem?
Or it does not. I was wondering why I was ending up with different versions under Windows and UbuntuOnWindows.
Turns out that any time you do something like “meteor update”, “npm install --save” or anything like that, the symlinks I created get blown out of the water and replaced by non-symlinked files.
Which is a bit contrary to the point why I created the symlinks in the first place!
I can only think that somehow any and all people in La-La-Node-Land deem it a good idea to read a configuration file, change the file in memory, delete the old file and write a new one.
While that makes sense from a certain perspective, this of course is simply deadly for symlinks.
Sorry, @sashko , but your company (among others) thus made my solution unusable. Because git (of course) doesn’t follow symlinks, thus leaving me with no easy way to synchronize UoW and Windows.
With 20 years in dev I know the feeling and it will not change apart from that down the road it will be entire languages and platforms you’ve put years into, that will be made redundant and you have learn new stuff. But I wouldn’t have it any other way. It’s progress and that’s good. Old timer out.
