Improve usability / consumption / awareness of Bash utility

[gireeshpunathil]

It would be a great idea to 'classify' and 'scope' capabilities in the power shell with compatibilities and retention of original meaning and purpose to that of native Linux - in terms of what is available and what is not. For example:

1. File system commands
2. Development + Runtime environments
3. Threading models
4. Networking capabiities / commands
5. Process management
6. Binary compatibility

[stehufntdev]

Thanks for trying out WSL. Can you please clarify the request? I didn't understand how bash relates to "the power shell"? If you haven't already, I would recommend reading through the "Microsoft Links" under https://github.com/Microsoft/BashOnWindows.

[gireeshpunathil]

@stehufntdev - powershell is a misnomer. I meant Bash on Windows itself. Keeping that aside, the questions / suggestions remain intact. I went through the sites, and could not find clear guidelines about what commands are supported, and what commands are supported with different connotations and implications, which has bearing on the underlying Windows system, etc. Also, it would be worthwhile to provide clarity on the "Program Execution Environment" (items 2 through 6 in opening comment represented by the BASH shell but executed by the underlying system. Example 1: Will a TCP socket data transfer rate adhere to the settings in the BASH, or the one set in the Windows registry? Example 2: Will two processes spawned in the shell follow the Linux default (or configured) scheduling policy, or that of the one prevalent in Windows?

[stehufntdev]

Thanks for the clarification! Unfortunately documenting every nuance and scenario at the user mode binary\library layer is a hard problem because WSL performs the emulation at the user->kernel boundary. Instead, we publish information for each insider build on what has changed and what the compatibility looks like through test suites.

For 1-6, I would recommend searching through GitHub for the specific tools you are interested in or checking out some of the community sites (e.g. https://github.com/ethanhs/WSL-Programs). If you have any specific questions that aren't answered in those please post them so we can answer.

[sunilmut]

@gireeshpunathil - Thanks for the idea. In general, I agree there is some merit in documenting some of points. But, scaling out to that is difficult (as @stehufntdev points out). Web is your friend. In addition to what @stehufntdev has mentioned, our goal is compatibility with Linux. So, if you are having compatibility issues, we would love to hear. If you are evaluating WSL technology for your business and it currently doesn't meet your needs, we would love to hear that as well. I would recommend pivoting the discussion around compatibility, because, ultimately, that's what it all boils down to.

In addition to the open forum pointed out by @stehufntdev, here is another one https://wsl-forum.qztc.io/ . I am sure there are more out there.

Thanks for your feedback!

[gireeshpunathil]

I eye language environments and virtual machines. As they provide a level of abstraction above the underlying system in almost all areas (or the ones I mentioned at a minimum), so curious to know what capability is available before we start with, porting them onto this shell. But your approach seem to be to claim full coverage of Linux, and address issues as and when they occur. Fair enough, I will go through the site and post questions as and when they occur.

One question still lingers: If a full Linux compatibility (at OS level) is envisioned, why calling BASH?

[gireeshpunathil]

dormant for 150 days. closing.