Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Done Tie-in to Win 10 x64's WSL Windows Subsystem for Linux

R

Rick Reinckens

Oct
364
17
I realize this would differentiate the 32-bit and 64-bit versions and also that wouldn't work on any pre-Win 10 version.

Theoretically, WSL currently doesn't support GUI, although with third-party programs such as X-Ming it can. This would give access to non-GUI things WSL does support, like various versions of BASH, Linux code libraries, etc. Basically, using it to send a command, etc., to WSL and have a value returned, or create a function that will access WSL and return a function value.
 
Hopefully the OP is referring to Windows Subsystem for Linux (WSL) and not the World Surfing League. :rolleyes:
 
Basically, the equivalent of TCC's current support for PERL, Python, RUBY, REXX, @WINAPI and @CAPI, except it allows accessing Linux code through WSL.

I don't know the current level of MS's Linux support in WSL. I assume that if it can't already do so, at some point it would be possible to run a Linux program or script, from Windows, rather than having to start bash and run the program/script from there.

For example:

C:\WSL "apt-get" "update"

This would mean "In the root of drive C:\ run TCC's WSL command and tell it to run the Linux program apt-get with the parameter "update" (no quotes)"
 
I don't get it ... do you want a non-Linux user interface to Linux commands? Why? It would seem that a Linux UI (why not bash?) is a better idea?
 
Rick Reinckens said:
Basically, the equivalent of TCC's current support for PERL, Python, RUBY, REXX, @WINAPI and @CAPI, except it allows accessing Linux code through WSL.
Click to expand...
This is flat out not possible. WSL is a SEPARATE SUBSYSTEM. Basically, an entire separate world, not connected to the rest of the running system.
 
Not correct.

Windows interoperability with Linux


Run Linux tools from a Windows command line

Run Linux binaries from the Windows Command Prompt (CMD or PowerShell) using wsl.exe <command>.

Binaries invoked in this way:

  1. Use the same working directory as the current CMD or PowerShell prompt.
  2. Run as the WSL default user.
  3. Have the same Windows administrative rights as the calling process and terminal.

For example:

CMD
C:\temp> wsl ls -la
<- contents of C:\temp ->
The Linux command following wsl.exe is handled like any command run in WSL. Things such as sudo, piping, and file redirection work.
 
vefatica said:
I don't get it ... do you want a non-Linux user interface to Linux commands? Why? It would seem that a Linux UI (why not bash?) is a better idea?
Click to expand...

For the same reason Microsoft is doing it--access to billions of lines of Linux code, routines, libraries, etc., directly from a Windows command line, and the same as TCC's current support of PERL, Python, etc.
 
I basically run Linux in GUI mode (mainly Linux Mint 18.2 on a Chromebox hacked to run other OS's), so I'm not terribly familiar with the Linux command line. I do have Ubuntu set up under WSL, but just for exploring.

It looks like by using wsl.exe it should be possible from within TCC to do whatever wsl.exe will do.

One possibility would be to create a set of TCC "envelope" commands/functions that take input in typical TCC syntax, convert it to wsl.exe format and pass it to wsl.exe, and take any wsl.exe output and convert it to typical TCC format/syntax.


use WSL.exe instead of bash.exe · Issue #51455 · Microsoft/vscode

Use wsl.exe instead of bash.exe on newer versions of Windows · Issue #49713 · Microsoft/vscode


Microsoft's details about how to run wsl.exe and wslconfig.exe

Manage Linux Distributions

It sounds like this definitely could use a configuration dialog similar to other TCC command configuration dialogs.
 
You might want to also set up a wsl / wslconfig configuration dialog as a separate free product--with a link to "Try JPSoft's other products".
 
Last edited:
Regarding "Not correct", I started writing the response and then tried using the forum's quote feature instead but couldn't get it to work.

Read the link Manage Linux Distributions. It's clear that it is already possible to access the Linux stuff from the Windows command line.

From in TCC v18 I just typed wsl.exe ls {enter} and it gave me a directory listing and came back to the TCC prompt.

I also tried their example of wsl.exe Get-VM and got this error message: /bin/bash: Get-VM: command not found

I also typed: wsl apt-get update {enter} and it ran.

So it's definitely fully interacting with bash.

I don't get into creating Linux scripts or doing things from the Linux command line, so I'm not familiar with things like Linux error codes, internal variables, etc. But it's clear that Microsoft intends to provide Windows programmers full access to Linux as if Linux were just a module of Windows or a set of API's. It seems likely TCC could have the same capability of interacting with Linux that it has for PERL, Python, etc.
 
How's that in any way related?…
If all you need is to be able to start WSL apps, in the same way you could suggest "embedding" half the programs on the earth. It's already possible and you don't need to do anything at all for it to work.
The "TCC's current support for PERL, Python, RUBY, REXX, @WINAPI and @CAPI" is done by loading appropriate libraries and exposing calls to certain functions of them through TCC commands.

This. Is. Simply. Not. Possible. With WSL. And will NEVER be possible due to the very nature of WSL as a separate subsystem.
WSL programs are NOT WINDOWS PROGRAMS, they are Linux programs. Binary incompatible with Windows.
 
AnrDaemon said:
How's that in any way related?…
If all you need is to be able to start WSL apps, in the same way you could suggest "embedding" half the programs on the earth. It's already possible and you don't need to do anything at all for it to work.
The "TCC's current support for PERL, Python, RUBY, REXX, @WINAPI and @CAPI" is done by loading appropriate libraries and exposing calls to certain functions of them through TCC commands.

This. Is. Simply. Not. Possible. With WSL. And will NEVER be possible due to the very nature of WSL as a separate subsystem.
WSL programs are NOT WINDOWS PROGRAMS, they are Linux programs. Binary incompatible with Windows.
Click to expand...

You obviously just don't get it. I'm not saying it has to be exactly the same as the others.

Being able to run Linux code from Windows and passing environment variables between the Linux subsystem and Windows means a Linux script could be written that does whatever the Linux part is intended to do and then have it put results in one or more environment variables and pass those back to the Windows system--in this case for instance as the result of a TCC function.

Basically, the TCC part would just pass certain things to a Linux "black box", and then a script within Linux written specifically to take output of the Linux activities would pass results back with environment variables that TCC could see either as results of a TCC function or as internal variables. (And I don't think "internal variable" would be a good idea.)

You also don't get that Microsoft is integrating Linux into Windows. The whole purpose of WSL is that a Windows program could tie in to Linux by passing commands and parameters, then receive the results and continue. We're not talking "half the programs on the earth". We're talking about access to hundreds of thousands of Linux routines and libraries by a "send to black box" and "receive from black box" approach.

I don't know if Linux has the equivalent of Windows error codes returned in variables but I assume it does. If so, there should be a way to also pass any of those in the "receive from black box" mechanism.

And as I also mentioned, the current wsl.exe and wslconfig.exe approach looks pretty messy and probably could greatly benefit from a settings dialog within TCC and such a dialog might possibly also be put out as a standalone product.
 
Perhaps something like this:

@CallWSL[command, parameters, names of environment variables the linux script/program will set that will be returned, names of variables for error codes to be returned]

and/or

CallWSL /c {command} /p {parameters} /v {variable names linux will set} /e {error code variable names linux will set}


A TCC dialog could set all of those and create the command/function string.

I haven't thought out what the function version would return.
 
Last edited:
As I had pointed out when I recommended a LIBRARY system, although it's possible to do the "envelope" approach now just with library routines, memory functions, etc., it's better to have a standard way built into the language.

Plus, a completely user-implemented approach won't have an associated dialog or Help entry.
 
From the Interoperability page:


Starting in 17063, WSL and Windows share WSLENV, a special environment variable created to bridge Windows and Linux distros running on WSL.

Properties of WSLENV:
  • It is shared; it exists in both Windows and WSL environments.
  • It is a list of environment variables to share between Windows and WSL.
  • It can format environment variables to work well in Windows and WSL.
 
I mention above about creating a configuration dialog tool, possibly even as a separate product, and I mention in another suggestion about being able to save and load dialog configurations.

Possibly include a save and load feature in a CallWSL configuration dialog even if it's not implemented for other commands.
 
Rick Reinckens said:
From the Interoperability page:
Click to expand...

Also from that page:
There are four flags available in WSLENV to influence how that environment variable is translated.

WSLENV flags:
  • /p - translates the path between WSL/Linux style paths and Win32 paths.
  • /l - indicates the environment variable is a list of paths.
  • /u - indicates that this environment variable should only be included when running WSL from Win32.
  • /w - indicates that this environment variable should only be included when running Win32 from WSL.
Flags can be combined as needed.
Click to expand...


And all that still leaves one wondering. I found this on github.
For instance, a WSLENV could be something like this:
  • WSLENV=FORWSL/u:FORWIN/w:GOPATH/l:TMPDIR/p
In the example,
  • the FORWSL variable is included in the WSL linux environment when it is invoked from Windows.
  • FORWIN is included in the environment for Windows commands when they are invoked from WSL Linux.
  • GOPATH is a list of paths shared in both environments. The list elements are separated by : in Windows and ; in Linux.
  • TMPDIR is a path shared in both environments. It must be translated from Windows to WSL paths, e.g., C:\Users in Windows must be translated to /mnt/c/Users in WSL.
Click to expand...
 
The Interoperability page indicates Linux commands can be performed by preceding with wsl{space}

How about a "WSL prefix" character, similar to the _ and @ prefixes TCC uses? If something is prefixed by the WSL prefix character, TCC will convert that to wsl{space} and pass it to WSL, e.g.:

^ls will be translated to wsl ls which will perform the Linux command.

Also, something equivalent to COMMENT ... END COMMENT, e.g.

START WSL

END WSL

Anything in between will automatically have wsl{space} prepended, so it will run in Linux.

Obviously, the name would have to be different, perhaps something like:

WSL_BLOCK

END_WSL_BLOCK
 
Last edited:
Also, add the TCC path to the Windows path. WSL is now set up that the Windows path is added to the Linux PATH. So, for instance, from within WSL on the Linux side you can simply type notepad.exe and it will run the Windows program.

I tried running TCC that way and got "not found". When I used the full path I got "Permission denied" because TCC needs to be run elevated. On the PC I tried it on I don't have the TCC path permanently added to the Windows path.
 
Last edited:
vefatica said:
Also from that page:

WSLENV flags:

  • /p - translates the path between WSL/Linux style paths and Win32 paths.
  • /l - indicates the environment variable is a list of paths.
  • /u - indicates that this environment variable should only be included when running WSL from Win32.
  • /w - indicates that this environment variable should only be included when running Win32 from WSL.
-- snip --

For instance, a WSLENV could be something like this:

  • WSLENV=FORWSL/u:FORWIN/w:GOPATH/l:TMPDIR/p
Click to expand...

This is looking more and more like something that really could benefit from a TCC-style settings dialog!
 
I did see something indicating that on the WSL side the paths could use Windows format but just with backslashes doubled.

From the Interoperability page:

As an example, the following commands will open C:\temp\foo.txt in notepad.exe:

BASH
$ notepad.exe "C:\temp\foo.txt"
$ notepad.exe C:\\temp\\foo.txt

I just tried this from a TCC 18 prompt and it works: wsl notepad.exe c:\\temp\\testfile.txt

Surprisingly, this also worked--note the spaces in the filename, but double-quotes not needed:
wsl notepad.exe D:\\Data\\Electoral College.txt

Also note that D:\ was not mounted in Linux, i.e., I didn't have to use a path of: /mnt/d/data
 
Last edited:
Rick Reinckens said:
For the same reason Microsoft is doing it--access to billions of lines of Linux code, routines, libraries, etc., directly from a Windows command line
Click to expand...

Kind of like you get a message from your bank ...

We've made some changes to your checking account.

Your account can now tie in to all the money in Fort Knox.

In order to use this, just put a notation on your check "Draw from Fort Knox." Instead of pulling the money from your account, the check will use what's in Fort Knox.
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate