4 ms·

> - You can launch Windows apps from bash. So I can basically do `code .` from inside bash and it will open VS Code in the linux sub-system folder? That's amaz

> - You can launch Windows apps from bash. So I can basically do `code .` from inside bash and it will open VS Code in the linux sub-system folder? That's amazing!

toolbox 10y ago
Just for reference, I've been doing this for a few months now. I'm not sure what's changed, but you'll need ubuntu 16 (you can uninstall 14 and reinstall WSL to get it) in WSL to do it.
- chrisper 10y ago
  Are you running the fast ring build? EDIT: Actually, since I am doing that as well, I just tested it. And yes, it all works!
- bitcrazed 10y ago
  You don't HAVE to nuke & reinstall your Linux environment to get up to 16.04 - we also support in-place upgrades too ... so long as you're running a Windows Insider build >= 14951 HTH
sbarre 10y ago
This is actually the (previously) missing feature that was preventing me from fully diving into Win10 + Bash.. very happy to see this
platz 10y ago
I was under the impression that only linux sub-system applications should be modifying files inside the linux sub-system. For example, using windows explorer to edit linux sub-system files would be a big no-no.
- bitcrazed 10y ago
  Yes, that is the guidance we're giving right now. See my post on this subject for more background: https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/ https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-n... However, it's fine to modify files stored in your Windows filesystem from within Bash, so if you were in `/mnt/c/dev/project/` and launched `code.exe ./`, Code would open the current (Windows-accessible) folder.
  - jaxn 10y ago
    First, I switched from OSX to Windows b/c WSL made it possible. There is some weirdness with the recommended file system sharing. Git on WSL sees files as modified after they have been checked in from Windows. It means I either use Git from the IDE or from the terminal, but not both. Excited to see how this continues to improve.
    - bitcrazed 10y ago
      Great to hear - welcome to the party! :) What you're seeing with git is likely to be caused by line ending differences. You've probably got "Convert line endings to Windows" configured in your Git on Windows, but "Checkout Linux line endings on Linux". Either way, both should match otherwise all your files will look different because ... well ... they will be ;)
  - jaxn 10y ago
    First, I switched from OSX to Windows b/c WSL made it possible. There is some weirdness with the recommended file system sharing. Git on WSL sees files as modified after they have been checked in from Windows. It means I either use Git from the IDE or from the terminal, but not both. Excited to see how this continues to improve.
kej 10y ago
Almost. `code.exe .` will do what you expect IF you are in a folder that's visible from the Windows side. If you're in a WSL folder, the Windows program will be run in C:\Windows\System32. It has worked well for me to make a symlink under ~ to /mnt/c/Users/myaccount/, and that way anything under that symlinked folder is visible to WSL and Windows programs.
- bitcrazed 10y ago
  Hi - yes, we register the '.exe' extension with binfmt that then triggers WSL whenever a .exe is launched, allowing us to go find and spawn the requested Win32 process. If you just want to type `code <filespec>` (without the .exe), then you can create an alias that resolves to code.exe. Same for Notepad, etc. :)
  - nailer 10y ago
    (HN: bitcrazed is Rich, the person presenting in the video) Hey Rich, can you (or colleagues) tell us any news on console? I get the vibe from Michael Niksa back in August [1] [2] there's a big changes happening that will fix readline-type stuff and I'd love to know more about this - I use ConEmu / Win32 SSH on Windows and it, was well as bash, seem to occasionally suffer from terminal-corrupting weirdnesses. I'd love to know more about the causes, the fixes, whether the fixes will make it into Creators Update, etc. [1] https://github.com/Microsoft/BashOnWindows/issues/111#issuecomment-238302654 https://github.com/Microsoft/BashOnWindows/issues/111#issuec... [2] https://github.com/Microsoft/BashOnWindows/issues/111#issuecomment-238592841 https://github.com/Microsoft/BashOnWindows/issues/111#issuec...
    - bitcrazed 10y ago
      Yes, we're essentially giving the Windows Console its biggest overhaul in > 30 years! It's important to remember that the Console was one of the first things Cutler & team implemented when they started NT itself, and it's been updated, patched, partially-enhanced and modified quite a few times in the last 30+ years! ;) We're in the process of modularizing much of the Console's internals, replacing particularly archaic parts with shiny new modern C++ collections, etc., removing unnecessary cruft, etc. ... while trying not to break anyone! Much of the work we're doing right now will result in Maximus5 & the Console2 / ConsoleZ / etc. teams having to jump through far fewer hoops to implement decent terminals on Windows. And while we're doing this, we're also enhancing the console to support *NIX VT sequences, adding 24-bit color, etc., working with several other teams around Microsoft who need Console changes to make their things work. This week, we are planning & building features for the NEXT OS release! As you can imagine, it takes considerable effort and care to do this and we've got a great team with Michael, Paul, Mike2 & Austin beavering away as I type. Actually; small lie - Niksa is on vacation this week re-charging his fuel cells before I chain him to his desk again ;) We'll be writing a series of blog posts in the coming weeks, summarizing what's new in Bash & Console in Creators Update, and will have some cool stuff to show off at Build 2017! I'll also be speaking at OSCON 2017 in Austin (same week as Build!!), so stop-by if you're in TX and want to chat about Bash / Console :) https://conferences.oreilly.com/oscon/oscon-tx/public/schedule/detail/55798 https://conferences.oreilly.com/oscon/oscon-tx/public/schedu...

> - You can launch Windows apps from bash. So I can basically do `code .` from inside bash and it will open VS Code in the linux sub-system folder? That's amazing!

toolbox 10y ago

Just for reference, I've been doing this for a few months now. I'm not sure what's changed, but you'll need ubuntu 16 (you can uninstall 14 and reinstall WSL to get it) in WSL to do it.

chrisper 10y ago
Are you running the fast ring build? EDIT: Actually, since I am doing that as well, I just tested it. And yes, it all works!
bitcrazed 10y ago
You don't HAVE to nuke & reinstall your Linux environment to get up to 16.04 - we also support in-place upgrades too ... so long as you're running a Windows Insider build >= 14951 HTH

sbarre 10y ago

This is actually the (previously) missing feature that was preventing me from fully diving into Win10 + Bash.. very happy to see this

platz 10y ago

I was under the impression that only linux sub-system applications should be modifying files inside the linux sub-system. For example, using windows explorer to edit linux sub-system files would be a big no-no.

bitcrazed 10y ago
Yes, that is the guidance we're giving right now. See my post on this subject for more background: https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/ https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-n... However, it's fine to modify files stored in your Windows filesystem from within Bash, so if you were in `/mnt/c/dev/project/` and launched `code.exe ./`, Code would open the current (Windows-accessible) folder.
- jaxn 10y ago
  First, I switched from OSX to Windows b/c WSL made it possible. There is some weirdness with the recommended file system sharing. Git on WSL sees files as modified after they have been checked in from Windows. It means I either use Git from the IDE or from the terminal, but not both. Excited to see how this continues to improve.
  - bitcrazed 10y ago
    Great to hear - welcome to the party! :) What you're seeing with git is likely to be caused by line ending differences. You've probably got "Convert line endings to Windows" configured in your Git on Windows, but "Checkout Linux line endings on Linux". Either way, both should match otherwise all your files will look different because ... well ... they will be ;)
- jaxn 10y ago
  First, I switched from OSX to Windows b/c WSL made it possible. There is some weirdness with the recommended file system sharing. Git on WSL sees files as modified after they have been checked in from Windows. It means I either use Git from the IDE or from the terminal, but not both. Excited to see how this continues to improve.

kej 10y ago

Almost. `code.exe .` will do what you expect IF you are in a folder that's visible from the Windows side. If you're in a WSL folder, the Windows program will be run in C:\Windows\System32. It has worked well for me to make a symlink under ~ to /mnt/c/Users/myaccount/, and that way anything under that symlinked folder is visible to WSL and Windows programs.

bitcrazed 10y ago
Hi - yes, we register the '.exe' extension with binfmt that then triggers WSL whenever a .exe is launched, allowing us to go find and spawn the requested Win32 process. If you just want to type `code <filespec>` (without the .exe), then you can create an alias that resolves to code.exe. Same for Notepad, etc. :)
- nailer 10y ago
  (HN: bitcrazed is Rich, the person presenting in the video) Hey Rich, can you (or colleagues) tell us any news on console? I get the vibe from Michael Niksa back in August [1] [2] there's a big changes happening that will fix readline-type stuff and I'd love to know more about this - I use ConEmu / Win32 SSH on Windows and it, was well as bash, seem to occasionally suffer from terminal-corrupting weirdnesses. I'd love to know more about the causes, the fixes, whether the fixes will make it into Creators Update, etc. [1] https://github.com/Microsoft/BashOnWindows/issues/111#issuecomment-238302654 https://github.com/Microsoft/BashOnWindows/issues/111#issuec... [2] https://github.com/Microsoft/BashOnWindows/issues/111#issuecomment-238592841 https://github.com/Microsoft/BashOnWindows/issues/111#issuec...
  - bitcrazed 10y ago
    Yes, we're essentially giving the Windows Console its biggest overhaul in > 30 years! It's important to remember that the Console was one of the first things Cutler & team implemented when they started NT itself, and it's been updated, patched, partially-enhanced and modified quite a few times in the last 30+ years! ;) We're in the process of modularizing much of the Console's internals, replacing particularly archaic parts with shiny new modern C++ collections, etc., removing unnecessary cruft, etc. ... while trying not to break anyone! Much of the work we're doing right now will result in Maximus5 & the Console2 / ConsoleZ / etc. teams having to jump through far fewer hoops to implement decent terminals on Windows. And while we're doing this, we're also enhancing the console to support *NIX VT sequences, adding 24-bit color, etc., working with several other teams around Microsoft who need Console changes to make their things work. This week, we are planning & building features for the NEXT OS release! As you can imagine, it takes considerable effort and care to do this and we've got a great team with Michael, Paul, Mike2 & Austin beavering away as I type. Actually; small lie - Niksa is on vacation this week re-charging his fuel cells before I chain him to his desk again ;) We'll be writing a series of blog posts in the coming weeks, summarizing what's new in Bash & Console in Creators Update, and will have some cool stuff to show off at Build 2017! I'll also be speaking at OSCON 2017 in Austin (same week as Build!!), so stop-by if you're in TX and want to chat about Bash / Console :) https://conferences.oreilly.com/oscon/oscon-tx/public/schedule/detail/55798 https://conferences.oreilly.com/oscon/oscon-tx/public/schedu...