Run binary via AppBundle created by cargo-bundle on MacOS

[sleek kettle]

I've got a binary and running cargo bundle on it, and double clicking the created App.app doesn't actually do anything
Ideally, I'd want it to open the default terminal and run that binary. But nothing seems to happen.

cargo new helloworld
cd helloworld

Cargo.toml:

[package]
name = "helloworld"
version = "0.1.0"
edition = "2021"
description = "hello world"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

[package.metadata.bundle]
name = "hello world"
identifier = "com.example.helloworld"

And now, running cargo bundle and opening the app does nothing?

[hybrid rampart]

a macos app will open without a terminal

macos is like linux in that terminal windows are not a feature of the OS but a feature of terminal emulator apps

so if you put something in an .app, it needs to be something that does something useful without any stdin/stdout

normally, starting an event loop and having a window + menu bar etc

[sleek kettle]

So, I should create an app like this one, that then use applescript to open a terminal and run a command in it to run the actual binary to run the executable?

[hybrid rampart]

if your goal is to make something double-clickable that opens a terminal then you don't need to make an .app at all

just double-clicking an executable will open it in the terminal

(in some cases it might help if you give it an .command extension)

otoh if you want an .app specifically for some reason (opening it from something that only opens applications) then starting with an applescript app might be a better idea

[sleek kettle]

We kinda need to ship it as an app, so that the experience is the same as opening any other application.

[hybrid rampart]

if you want "same as any other application" then you really cannot use the terminal

macos apps do not open terminals

that is out of the scope of what a standard application does

apps have their own UI, always

if you're going to open a terminal then users will not mind more that it isn't an .app

[sleek kettle]

Hmm.
We do have a UI but the executable spawns the UI, which is a tauri app.

[sleek kettle]

Hmm

[hybrid rampart]

okay, so why do you need a terminal?

if you have a macos UI it is important that the executable that operates the UI is the executable in the bundle; certain things will be subtly broken if you don't

[sleek kettle]

Well, the actual binary is just a binary, that communicates to the spawned GUI via stdout

[sleek kettle]

Hmm.

[hybrid rampart]

eh?

you can use stdin/stdout with child processes without involving a terminal

but, you really should make the executable that is in the binary be the one running the GUI

I forget exactly what goes wrong if you don't but it can be weird

[sleek kettle]

Hmm.

[hybrid rampart]

there should be no need for anything else, if you are making a GUI app

if you have a need for another process, have the GUI process spawn the other one, not vice versa

[sleek kettle]

I tried doing something like:
App.app opens the main_cli_binary -> which spawns a GUI
But double clicking the app exported doesn't actually do anything, the GUI isn't spawned. But running open ./App.app it works as it should.
So I thought there must be a way to ensure that it opens the same way when double clicking.

[sleek kettle]

Hmm, yeah should probably do this.

Or combine the GUI and the main binary.

[hybrid rampart]

if open works but double-clicking doesn't … that's moderately weird

when you say it doesn't work you mean there is no effect, or an error?

[sleek kettle]

No action / effect

[hybrid rampart]

might be down to environment variables or something

open can actually do some weird things that normal app opening never does

or maybe the cwd? is your binary in the bundle assuming a particular cwd?

[sleek kettle]

No

[hybrid rampart]

well, I would suggest having the binary you have log things to a file for debugging

[sleek kettle]

It does so some stuff with the PATH variable, maybe that's causing it.

[hybrid rampart]

it used to be possible to grab apps' stdout by running Console.app but unfortunately that doesn't seem to work in recent os versions

[sleek kettle]

We do.
And it also works when you double click the binary.

[hybrid rampart]

one thing to remember is that in macOS the GUI environment does not go through any shells whatsoever

so any environment variables set up in your .profile or .bashrc or whatever will not be applied

[sleek kettle]

OH

[hybrid rampart]

so for example if you are doing a cargo run …

[sleek kettle]

Oh okay.

[hybrid rampart]

it won't find cargo because it will only be checking /bin:/usr/bin and not any customizations such as by rustup

[sleek kettle]

Hmm

Argh, yeah, that's probably what it is.

I'll try writing the full path

So yeah, it was the lack of PATH variable resulting in no effect.

But its interesting that apps don't go through shells