Hacker News Reader

Comment by klagermkii | Hacker News Reader

This is a pity. One of the things I like with the Mac is being able to use Mac-side editors like BBEdit to be able to make changes to the configuration and files of the Unix-y server tools I need. If I can't reliably use Windows GUI editors that would limit my ability to migrate from macOS.

If one is running NGINX/PHP under WSL would one not even be able to safely edit .php files?

View on HN

The lxss folder is for things you only want to access from Linux. Things like a .php file you want to access from both sides goes somewhere else. In Windows you go to C:\MyPHPFiles and in Linux you go to /mnt/c/MyPHPFiles.

This. I use WSL daily and edit in both Linux & Windows... but the files I'm dealing with are in a directory structure that set up on the windows side and I get to them through /mnt/<drive letter>. Completely painless for me.

I do have to occasionally edit Linux config files and whatnot and, yes, I do that with emacs or vim (depending on mood), but it's honestly not often and I personally prefer the terminal based editors in Linux for that better (yeah, a preference thing there... ).

Anyway, been working like this since before the Anniversary Update on the later insider builds and it's been pretty solid and seamless for me.

Have you tried using an xserver to run GUI Linux apps through it? If so, how's the delay? Is it instant and ready for full time development?

Use case would be wanting to use an editor that can take advantage of programming runtimes installed on the Linux side of things.

Think about using Sublime, where you'd want to run a Python linter. In this case Sublime needs to be installed and ran in Linux alongside your Python installation.

You can run bash.exe with command line options to start specific Linux applications. I setup the Windows VSCode to run use Bash as it's terminal and the build actions to trigger Linux programs.

I've run a few small GUI applications and the performance was pretty much native-level. I use VcXsrv as my X server. I've read that some people run entire Linux tiled window managers through WSL without complaint.

Can you go into more detail on VSCode's terminal?

I would have expected VSCode (and Sublime/Atom/etc.) to need to be running on Linux to leverage the run-times installed in Linux.

How does it handle code complete for user written code when:

1. You have VSCode installed in Windows

2. You have your language and all packages installed in Linux

3. You have your source code sitting in a folder on Windows

Edit:

Since you edited in some info about xserver performance, that's awesome.

What type of specs is your machine?

Bash.exe is a Windows console application as far as every other application is concerned. So for VSCode to run it instead of Cmd.exe, is really nothing at all. Same with other tools.

I'm mostly using it to C/C++ development for an embedded platform so my experience with code completion, etc, is a bit different. But it does work as well as it does on a pure Linux installation.

I have a pretty powerful desktop but I run the same configuration on my i5/4GB laptop and the performance is still good (and why not, it's all native code). I think there might be some disk performance issues but I haven't compared it too closely. I prefer it over using a VM just because of the integration and convenience.

Originally it sounded like you had VSCode installed on Windows but you're able to get all of the goodies (context sensitive code complete based on files in Linux) of it running on Linux -- without VcXsrv running on Windows.

I guess I just don't get how VSCode that's running on Windows can "see" and use the Linux filesystem. Is this something MS did that only works for VSCode (ie. it wouldn't be available with Sublime/Atom)?

Also it looks like VSCode doesn't work through VcXsrv according to this issue: https://github.com/Microsoft/vscode/issues/13138

> I guess I just don't get how VSCode that's running on Windows can "see" and use the Linux filesystem.

I can't. It's the other way around, the Linux file system can see the Windows one. So VSCode's code complete is based on files on the Windows system but the Linux side can also see those files and compiles/runs them. Linux doesn't know it's a completely different file system; it's just another path.

I imagine most web developers would have Python, Ruby, Elixir or whatever they use installed on Linux. That would be both the run time as well as all packages required for their projects.

Then they would have their app level code off in a Windows folder to avoid corruption and having it accessible on both sides (makes 100% sense).

The confusing part is understanding how VSCode running in Windows is able to make sense of all of that.

That would mean VSCode would need to know that the runtime and packages are at "the private Linux FS path from within Windows", while app level code is at "some Windows path of your choosing". You're saying it does this flawlessly, and then there's no need to even mess around with xserver?

I don't use VSCode but I would guess it needs to know things like your Python path or Ruby path, etc.. These are things that would be installed on the Linux side of things. That's where it falls apart in my head.

VS Code isn't going to be able to read any files on the Linux side but it can execute Linux applications against your Windows working folder. So having VS code run Linux Python to test will work. If code-completion works by reading package source files installed in the Linux partition, it's not going to be able to do that.

For my development needs (embedded C/C++) this is not an issue.

> These are things that would be installed on the Linux side of things. That's where it falls apart in my head.

You setup your environment to run Bash.exe with the appropriate parameters to start the Linux application.

   bash -c "linux command here"

http://winaero.com/blog/run-linux-commands-from-cmd-exe-prom...

Yeah, it would need to reference package source files from Linux for code complete to properly work.

Thanks for the replies, that clears things up.

I have not. I use Sublime on the Windows side; in those cases where I have issues like linting I'm just doing it via the Windows equivalent (I'm not working with Python) and having a different source for linting vs. some of the runtime environment hasn't been a problem for me... though I could see where you'd want something more apples = apples.

For myself, an xserver is probably more overhead than I'd want to take on... I'd just drop WSL and go back to my VM at that point (different pain points, but simpler pain points).

That's unfortunate. Having to "double install" things like that is very inconvenient.

Yep, I use a VM now (a seamlessly integrated one with vmware) but sadly vmware support for Unity mode Linux guests has been dropped and VirtualBox has too many problems to consider using.

Was hoping to eventually change to Windows 10 but it's sounding like I might as well stick with what I have now, despite the bugs and being stuck with a ~4 year old Linux distro because nothing else works.

If Windows can solve the problem of running GUI Linux apps through it, I'd be the happiest developer ever.

I use Xming and it works pretty seamlessly for both local applications and X-forwarded ssh sessions

Nice, is that the free version of xming?

I had ~3 seconds of typing delay and a lot of visual graphical tearing on an i5 with an SSD and plenty of RAM (with SSH compression enabled) when I tried to use it on a locally running vmware VM under Windows 8 but I can't test it on 10.

Is it purely instant on 10, to the point where you would feel happy typing / looking at it all day?

What editor were you using in xming?

According to MS, vscode doesn't work and perhaps all Electron apps wouldn't work: https://github.com/Microsoft/vscode/issues/13138

Do windows people have any respect for the idea of home folders? You should put your own files in /home/blah/foo or C:\Documents and Settings\blah\foo, not /myfiles or C:\myfiles

That was just for illustrative purposes. Your personal files should indeed be under C:\Users\name\

Like the article says. You point your Nginx to serve files out of the "c" drive mount point.

You can work this way beautifully; just do it from the Windows file system as intended and don't delve into the hidden/system files that back the Linux subsystem.

No, at least not from that directory. You need to use tools that know how to update the WSL-specific metadata in the NTFS extended attributes, and Windows programs do not do that. You would need to set up a file server so that the programs could communicate using a standard protocol.

Edit: or as hartator says in another thread, store your files somewhere under /mnt/c/.

Reply on news.ycombinator.com