How to run a console application?

How to run a console application?
I tried this without result:

Var xpfile As FolderItem = SpecialFolder.Library.Child("x").Child("y").Child("")
If xpfile.Exists then
  if xpfile <> Nil then
    sh.Execute("open -a " + xpfile.ShellPath)
  MessageBox("File not found !")
  exit sub


First off you have your nil and exists check the wrong way round. if xpfile result is nil, xpfile.exists will throw a nil object exception. Equally you can get a nil object exception from items like this:


if the x folder doesn’t exist or the y folder doesn’t exist they will generate a nil object exception.

That I didn’t think console applications had .app on the end of their name? I don’t currently have a licence to build them so I can’t check, but as far as I can recall they’re not application bundles?

You would run it as follows:

sh.Execute(xpfile.ShellPath + " any parameters here")
1 Like

Other considerations -

Are you expecting any results from the command line tool?

Var xpfile As FolderItem = SpecialFolder.Library.Child("x").Child("y").Child("destfile")
Var sh = New Shell

sh.mode = 1
sh.Timeout = -1

If xpfile <> Nil And xpfile.exists then
    sh.Execute xpfile.ShellPath
    Loop Until Not sh.IsRunning
    If sh.ErrorCore <> 0 Then
      // error occurred
      // deal with the result
    End If
  MessageBox("File not found !")

We’ve also used other shell modes to read data from the console app before it completes. Which allowed us to produce percentage completion information as the console app proceeded.

If you’re going to be running a console application for some time (on a Mac), you may want to look into alternatives to the Xojo shell.

I wrote about the energy inefficiencies with the Xojo Shell in this thread. Energy inefficiency in Xojo

1 Like

I have questions about this code:

Is this safe to do? I’ve always avoided putting the Nil and Exists checks on the same line thinking that Exists might trigger an NOE.

Why would you do this as opposed to just using Synchronous mode? Are there advantages?

This is ok. Because it would leave the condition the moment xpfile is NIL.

1 Like

To elaborate a little on what @Sascha_S said, this is safe because of the use of “and” instead of “or”, which allows Xojo (and most but not all languages) to immediately know the IF statement will be false and not bother testing the other condition(s).

Had this been OR, then both conditions would need to be tested.

And some languages are not optimized enough and will test all conditions even after finding the preceding condition(s) will cause the whole IF to be false. So you may have this idea because of a problem with a prior programming language.


It is using Synchronous mode (and could even be Asynchronous), but using the Do … Loop Until loop with the sh.Pool call allows the UI to remain responsive while the shelled task is executing. It also means that you’r function doesn’t move forward until the CLI tool finishes.

In fact - and I get fussed at about this religiously - I also add a call to App.DoEvents(5) for even better responsiveness.

  // handle shell stream data here
Loop Until Not theShell.IsRunning

The reason that this works is that my use of a Shell in this manner is more Functional programming that OOP, so the run order is consistent and doesn’t interfere with other things going on in the parent UI app to worry about recursion. That also works in a Thread as long as you’re not updating the UI from within that loop.

Not necessarily:

Var f As FolderItem

if True or f.Exists then
  MessageBox "Something."
end if

(you get the message box and no exception)

That’s not because the operator is “or” that both conditions are evaluated.

Quite correct. What I should have said is that as soon as the statement is known to be true or false, it can “short circuit” the rest of the tests. In the context of the original question, it was known to be false after testing the first condition so the second is not evaluated.

In your example, it is known to be true to there is no need to test the other conditions.

I believe this is known as “short circuit” in compiler terms, and it behooves oneself to know if the language in use performs it or not.

I understand the point and it is well made. However, for our purpose compared with the fact we are running upto 124 cores at full pelt for days a few % for the monitors are not a major issue. :slight_smile:

I’d love to see what a Mac with that many cores would look like :scream:

1 Like

The killer Hackintosh:

AMD Epyc 9654 96 Cores, 192 Threads 3.55GHz per core
ASRock RACK GENOAD8-2T Motherboard
512GB ECC Memory
Open Core Mac boot environment
Build cost ~US$23K

1 Like

I don’t think macOS would run on that CPU.

I have no idea what the cost is with the Windows Shell, but if it’s like the Mac shell, you could use the savings towards what you’re actually doing, instead of… what ever it is that Xojo is doing. 5% CPU usage over days could add up to something significant.

Ha… I doubt we’ll ever see one, Apple hasn’t

built server grade hardware for a long time, I’m not even 100% they build “Professional” grade hardware anymore with everything soldered in and un-replaceable.

They still support x86 for the time being, but it’s days are numbered.

Hence my question.

Yes, but according to Hackintosh people it won’t run on AMDs thread rippers, for example.

Their Intel Pro hardware is pretty good even today.