6 ms·

Ok, this is awesome, if everything works as advertised. I have been mostly a Linux user for quite some time - at least on my own computer, clients always have

Ok, this is awesome, if everything works as advertised. I have been mostly a Linux user for quite some time - at least on my own computer, clients always have Windows. But this year I bought a Surface Pro as a secondary device. I first evaluated WSL and really liked it, but I switched to Hyper+Git Bash because networking in node.js was not working properly, and because I could not start Windows programs from the command line. Now, if both problems are really fixed now, I guess I will switch back to WSL, and maybe uninstall Hyper+Git Bash later (given that I do not find any other show stoppers)...

Osiris 9y ago
I recently tried starting Windows CLI programs from within bash and it worked just fine, but you have to specify the entire filename, like "./notepad.exe".
- nsebban 9y ago
  This is usually because, by default on many Linux flavours, the current directory is not included in your path environment variable.
  - kwhitefoot 9y ago
    This is generally the case in all Unix shells. See, for instance, https://superuser.com/questions/156582/why-is-not-in-the-path-by-default https://superuser.com/questions/156582/why-is-not-in-the-pat....
  - vic-traill 9y ago
    Just to note that this (to run scripts/executables you must specify the cwd in the cli invocation)is also the case for PowerShell. So, not unknown in the Windows world.
  - JdeBP 9y ago
    Actually, given what Osiris appears to be getting at, it is because Unix shells in general have no notion of a PATHEXT system, and so do not go around tacking .COM, .CMD, .EXE, and the like onto the ends of command names. The not searching the current directory is well known in the Unix and Linux world; and to be fair so too is the idea that if the filename of one's executable Perl script ends in .pl, or the filename of one's executable shell script ends in .sh, then the .pl and the .sh have to be explicit in the command name that one types. The idea that one can run notepad.exe with just notepad comes very much from the DOS and Windows world, here. The Windows NT POSIX Subsystem actually provided a whole bunch of shims so that one could run various Win32 housekeeping utilities from a POSIX shell without explicitly adding ".exe", and a Korn shell adjustment to allow case-insensitive searches for Win32 commands. * https://technet.microsoft.com/en-gb/library/bb463210.aspx https://technet.microsoft.com/en-gb/library/bb463210.aspx
ghshephard 9y ago
What's interesting about the Windows approach, (and I realize you know this) is you don't cease being a Linux user - they are effectively running a instance of Ubuntu (previously 14.04, now 16.04) - so most of the linux fu you are used to, translates directly to WSL. The Anniversary update was intriguing, but there were little nits in things like networking, file/process access between windows/linux environments, that made it just as easy (for me) to simply run a VM instance. Creators Update looks like it's resolved pretty much 100% of the top issues on my nit list - it's going to be really interesting to see I switch my workflow from VMs to working with WSL.
sratner 9y ago
Unfortunately, I found Windows command-line interop isn't as useful as I had hoped. You can start Windows executables, but you can't kill them: ctrl-c gets you your shell back, but the executable is still running in the background, headless. See: https://github.com/Microsoft/BashOnWindows/issues/1614 https://github.com/Microsoft/BashOnWindows/issues/1614 And since USB ports aren't mapped into WSL, I have to use a Windows program to talk to them. Besides this hiccup, everything else seems to work great.

Osiris 9y ago

I recently tried starting Windows CLI programs from within bash and it worked just fine, but you have to specify the entire filename, like "./notepad.exe".

nsebban 9y ago
This is usually because, by default on many Linux flavours, the current directory is not included in your path environment variable.
- kwhitefoot 9y ago
  This is generally the case in all Unix shells. See, for instance, https://superuser.com/questions/156582/why-is-not-in-the-path-by-default https://superuser.com/questions/156582/why-is-not-in-the-pat....
- vic-traill 9y ago
  Just to note that this (to run scripts/executables you must specify the cwd in the cli invocation)is also the case for PowerShell. So, not unknown in the Windows world.
- JdeBP 9y ago
  Actually, given what Osiris appears to be getting at, it is because Unix shells in general have no notion of a PATHEXT system, and so do not go around tacking .COM, .CMD, .EXE, and the like onto the ends of command names. The not searching the current directory is well known in the Unix and Linux world; and to be fair so too is the idea that if the filename of one's executable Perl script ends in .pl, or the filename of one's executable shell script ends in .sh, then the .pl and the .sh have to be explicit in the command name that one types. The idea that one can run notepad.exe with just notepad comes very much from the DOS and Windows world, here. The Windows NT POSIX Subsystem actually provided a whole bunch of shims so that one could run various Win32 housekeeping utilities from a POSIX shell without explicitly adding ".exe", and a Korn shell adjustment to allow case-insensitive searches for Win32 commands. * https://technet.microsoft.com/en-gb/library/bb463210.aspx https://technet.microsoft.com/en-gb/library/bb463210.aspx

ghshephard 9y ago

What's interesting about the Windows approach, (and I realize you know this) is you don't cease being a Linux user - they are effectively running a instance of Ubuntu (previously 14.04, now 16.04) - so most of the linux fu you are used to, translates directly to WSL. The Anniversary update was intriguing, but there were little nits in things like networking, file/process access between windows/linux environments, that made it just as easy (for me) to simply run a VM instance. Creators Update looks like it's resolved pretty much 100% of the top issues on my nit list - it's going to be really interesting to see I switch my workflow from VMs to working with WSL.

sratner 9y ago

Unfortunately, I found Windows command-line interop isn't as useful as I had hoped. You can start Windows executables, but you can't kill them: ctrl-c gets you your shell back, but the executable is still running in the background, headless. See: https://github.com/Microsoft/BashOnWindows/issues/1614 https://github.com/Microsoft/BashOnWindows/issues/1614 And since USB ports aren't mapped into WSL, I have to use a Windows program to talk to them. Besides this hiccup, everything else seems to work great.