Is it possible to use WSL as my Build terminal instead of cmd.exe?

[pbrightly]

I've been on Windows since they ditched OS/2.  Ironically, most of my work is on linux hosts using mostly bash and python.  When MS created WSL, I became a very happy man.  I can't tell I'm not on native Ubuntu.  So I (mostly) ditched cmd.exe as well.

My development environment shares a filesystem between Windows and WSL-Ubuntu.  I run all my GUI apps, including Slick on the Windows apps.  I do all command line work in Ubuntu (a significant amount).

I'd MUCH prefer to debug my python & bash within Slick.  Is there a way to configure the Build window to use WSL instead of bash?  Can I setup my project tools to call things installed in WSL?  That's where I work.

If I can't do that....can I setup remote debug against localhost to get at WSL?

Again..I've been editing with SlickEdit for years, on the windows side.  The filesystem is shared, so I can run (and edit) things in WSL fine. They work well together.

PS. I'm new to SE2020. I'd been using 2008 since it was new.  Very happy to see a python debugger.

[patrick]

It looks like on windows the build shell is constrained to be cmd.exe.

SlickEdit doesn't have built in logic to deal the logical boundary between the Windows environment and WSL. (or any other type of hosted VM). So while you can slightly cheese it by doing something like "wsl.exe python3 /some/py.file" to run python under WSL, when SlickEdit needs to expand paths for project tools, set the working directory, etc..., they're going to be windows format paths, and not unix paths that reference the mount layout of your WSL setup.   So that will break a lot of things. 

As a short example: you run a python program with that wsl.exe command, and there's a syntax error.   You hit your keybinding to go to next-error, and at best you get prompted for the source file location, because it will try to interpret the source file in the error message as a windows path.

As far as debugging python goes, I think the path issues would make it so you can't start debugging the program by hitting F5.   If you can make TCP connections from the windows side into the WSL side, then you could treat it as the remote debugging case which is described in the manual.

While it's possible to go from the other direction and run SlickEdit on the WSL side (if you have an XServer running in windows), it's not a configuration we test with.  We know some customers have done it, and reported some windows not giving focus to the right control when it comes up.  (not super surprising, we have seen similar with less common window managers on Linux).   Microsoft is going to be providing a XWindows server for WSL that can support graphics acceleration, it's in preview now.  I am interested in seeing how we work with that, but I can't predict if it's a configuration we'll test with or not.

[pbrightly]

Interesting. A little disappointing, but perhaps there are some things I could do.  For instance, you gave me an idea for running my bash scripts.  I added another custom tool to the build config called "Exec Bash".  Non of the %* vars worked to let me expand the directory properly.  But if I hardcoded the WSL path (which is identical to windows path with forward slashes), I got it to run.
Using the normal expanding variables in the config, it fails:

Code: [Select]

C:\sandbox\integration-testing> VSLICKERRORPATH="C:\sandbox\integration-testing"
wsl bash ./deploy_server_base.sh
bash: ./deploy_server_base.sh: No such file or directory
Hardcoding the path and passing it to "wsl bash":

Code: [Select]

C:\sandbox\integration-testing>set PATH=C:\Python3;C:\SlickEdit2020\win;C:\Python3\Scripts\;C:\Python3\;C:\SlickEdit2020\win\;c:\java8\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Plantronics\Spokes3G\;C:\Program Files\Cloud Foundry;C:\Program Files\PuTTY\;C:\Program Files\IBM\Cloud\bin;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\VSCode\bin;c:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;c:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Git\cmd;C:\Git\mingw64\bin;C:\Git\usr\bin;C:\Program Files (x86)\Sennheiser\SenncomSDK\;C:\Program Files\Docker\Docker\resources\bin;C:\ProgramData\DockerDesktop\version-bin;c:\cmd;c:\tools;c:\slickedit2008\win;C:\Program Files\Docker Toolbox;C:\Users\PaulBrightly\AppData\Roaming\Dashlane\6.1907.0.17833\bin\Firefox_Extension\{442718d9-475e-452a-b3e1-fb1ee16b8e9f}\components;C:\Users\PaulBrightly\AppData\Roaming\Dashlane\6.1907.0.17833\ucrt;C:\Users\PaulBrightly\AppData\Roaming\Dashlane\6.1907.0.17833\bin\Qt;C:\Users\PaulBrightly\AppData\Roaming\Dashlane\6.1907.0.17833\bin\Ssl;C:\Users\PaulBrightly\AppData\Roaming\npm;C:\Users\PaulBrightly\AppData\Local\Microsoft\WindowsApps;C:\Users\PaulBrightly\AppData\Local\Box\Box Edit\
C:\SlickEdit2020\win\vsbuild -signal 60889 -command wsl bash /sandbox/integration-testing/tools/bin/deploy_server_base.sh

C:\sandbox\integration-testing> VSLICKERRORPATH="C:\sandbox\integration-testing"
wsl bash /sandbox/integration-testing/tools/bin/deploy_server_base.sh

-------------------------------------------
--- deploy_server_base.sh
-------------------------------------------
(that banner is all the script output for now)

Windows has no problem with using forward slashes in double quoted pathnames or in api calls.  It's parsing on the windows command line that gets you in trouble.  That being the case... perhaps "some" form of support could work here. At least in the case I show above.  I'd like to explore it.

On running the linux version "in WSL".. I'm not a big fan of running X when I've got a nifty windows app. I'd do it for a superior debug experience, but I'm on a shared license for both Win & MacOS, so... I can't in any case.
(assuming the windows license doesn't work for linux in WSL on same box??)

[Clark]

Works for me.

Macro>Set Macro Variable

set variable "def_ntshell" to c:\windows\system32\wsl.exe --exec bash -i

You will need to exit the build shell if its running (or restart slickedit).

Keep in mind that you will have to invoke commands that work under Linux. You may need to set your own custom build commands or choose configs which work under Linux.

There are some limitations. Error message processing won’t work due to the paths being totally different. This is the worst problem. SlickEdit project code will try to change directory, set VSLICKERRORPATH, and on rare occasions create a temp batch file to be deleted to work around extremely long command lines. None of these things will work. Usually you can get by with these things not working. Ctrl+C seems to kill the bash shell but that's not a big deal because the next menu build command you execute will restart the shell. The only potential issue with this is that you will get restarted in the current directory of SlickEdit which may not be the current directory of the shell that was just killed.

[pbrightly]

This is definitely interesting and something I'm pursuing. Getting the shell to be wsl was easy with a simple set-var!  Works great. But I really struggled with  the environment.  I'll go back and give better notes if desired.  Off the top of my head:

• parens in paths '(' ')' were wreaking havoc -- I went so far as to change my system path and replace that with DOS short-path names
• In some cases vsbuild wasn't found or my environment was being set windows style within wsl -- you know how that went -- I actually linked vsbuild executable path into my regular path under a name that gets rendered with all the backslashes and that worked, hackish is it was
• An example on the item above -- I had an execute-config using the hacks above that actually worked... the first time. Next run, my environment was so boogered up, I'd have to quit wsl and restart
• I had to hardcode paths for wsl. A pity since my paths are identical on windows and wsl sides, except one uses back slashes and other uses forward.  A double pity, as Windows APIs don't care.  In fact, if I double quote, I can use forward slashes on slicks command line.
  
• There's more, but I didn't take notes, so.. will expand if desired

What works great, is what I did in the past.  Just write a macro and bind to a key sequence.  Maybe we should have a macro option for configuring build-menu items?

[pbrightly]

doh. I just noticed the checkbox for "Command is Slick-C macro".  Guess I'll dig into the docs.