Windows Shell from MBS - Command Line limitations?

Hi Christian and all,

I’ve run into the issue where the Xojo Shell is not passing input to the executed application. To sort this, I’m moving to the MBS Windows Shell (Windows Process Execute).

When running the example application (19r3.2, MBS 20.3), The task fails with an Error 2 - the system cannot find the file specified. The command line entered is:

“C:\ProgramData\TOLIS Group\ArGest Backup\bin\bru.exe” -cvvvvvvvvvlAOf \.\tape0 -b 2m -L “MBS Shell Test” “H:\28GB short crossover”

The app path for bru.exe is correct and that command runs properly from the CMD.EXE command line.

Are there special considerations when passing strings that need to be encapsulated in quotes like this?

The issue is specifically related to the handling of command line elements containing spaces or special characters. The quoting mechanism seems to be completely ignored.

Once I got everything down to no spaces, the task runs properly and I can now communicate with it, unlike the Xojo Shell implementation.

Any ideas on how to pass arguments containing spaces?

Use a declare into Windows execute process which I have laying around here somewhere

What does this line look like in your code on the call to mbs shell.execute? Shouldn’t you be putting the args into a param array so they shouldn’t need to be quoted? I can never find the docs on the mbs site its a nightmare to navigate :frowning: Anyone got a link to the page?

https://www.monkeybreadsoftware.net/class-windowsprocessmbs.shtml

Cheers @Norman_Palardy .

@Tim_Jones , which one are you using WindowsShellExecuteMBS or WindowsProcessMBS?

Sounds like he is using WindowsProcessMBS class. There is also ShellMBS for cross-platform usage. And like other classes, they exist to do more/better then the Xojo shell class.

And using quotation marks is an example given at MSDN:

LPTSTR szCmdline = _tcsdup(TEXT(“"C:\Program Files\MyApp" -L -S”));
CreateProcess(NULL, szCmdline, //);

I was using WindowsProcessMBS based upon your example.

I’ve now shifted to ShellMBS, but there are some further differences I’m looking at that don’t mesh directly with the Xojo Shell class. It’s also handy to tap into stdout and stderr separately instead of having to use 2>&1 on every command …

So that understand without polluting my expectations with Xojo’s Shell, is your ShellMBS more like using execve in C?

For Windows, the WindowsProcessMBS and ShellMBS classes do basically the same.

On Linux we use execve for ShellMBS class, for Windows CreateProcessW and for macOS we use NSTask currently.

Can you post a snippet of the code setting up the call to WindowsProcessMBS?

Check out the example that Christian provides in ./Win/Windows Shell.xojo_binary_project.

Just testing something " "

“ ”

Did you paste in curly quotes into the demo app? Because you pasted curly quotes in the OP, or was that something the forum software did? If those make it into the demo app’s command line field, it comes back with error 2 but it works when pasted into a cmd window as they are translated into the correct versions.

Nope - I have smartquotes disabled on my Windows system. I also double-checked them in the Xojo debugger.

As an aside to this, the issue that I’m trying the end around turned out to be a change in the way Windows handles stdin/stdout/stderr redirection. This resulted in my Unix tools suite not working on the newest Server or Windows 10.

I was using CreateFile using CONIN$/CONOUT$/CONERR$ instead of the more modern GetStdHandle(). On new systems, trying to read from CONERR$ fails.

I am still going to refactor the code to use ShellMBS because Christian’s offering of access to the standard I/O channels is a help in the long run.

1 Like