I'm coming in late here, but I see MacOS and /tmp being at issue, and
it's possible
Apple's weird new permission stuff might be getting triggered here?
[...] Perhaps apps need special access to /tmp?
Side note: it looks like "/tmp" is in reality "/private/tmp" which looks
like one of these mechanisms to make things really "private". I found
this out (accidentally) by using test/demo, enabling the "debug
terminal" and watching the output. Somehow "demo" gets the "real"
directory string. This may or may not have to do anything with the issue...
Anyway, to detect this "new" security stuff, you have to use the
/System/Applications/Utilities/Console
to monitor these errors while the app is running, as such errors
often don't get reported via
traditional unix mechanisms like errno and strerror(), and often
post dialogs asking for access
to things.
Great hint, thanks!
So if you suspect weird new Apple security stuff, first run the
Console app (mentioned above),
and hit "Start streaming", then run your app and watch for weird
error messages about your
app in the console.
The console is /very/ chatty, so you have hit "Pause" so you can
scroll around or Copy/Paste
into an editor to find errors/warnings related to your app.
I used the "search" feature and selected either "Process" fluid or "PID"
and its PID. See attached logs.
Apple's error messages in this log
about the new privacy stuff are often quite clear about what the
security/privacy problem is,
and it can sometimes be related to how the process was started,
and what limitations are set
in place for that. For instance often the /bin/sh or /bin/bash has
limitations on it that prevent
users from running things from that shell.
I can't find anything useful in these logs which I'm attaching. In both
logs 'fluid' is started, once by running `fluid/fluid` (relative path:
this hangs) and the other by `/tmp/fltk/fluid/fluid` (full path: works).
Maybe someone else can see what's happening or can test on their
system(s). Mine is macOS Ventura 13.1 on MacBook Air (M1).
The names of the logs are self-explanatory, and as far as I can see they
are very similar until the "hanging" fluid stops. Notable difference:
the "working" process issues "SetFrontProcess: asn= options=1" somewhat
later than the hanging process - and continues to work and logs more
messages.
Maybe someone else can find the underlying issue and maybe even find a
workaround?
Maybe it *has* to do with the hidden "/private" in the working directory
and app directory before "/tmp"?
Comments are owned by the poster. All other content is copyright 1998-2025 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.
