I am developing an ncurses program. So running this in Xcode fails because the Console is just for stdout/stderr, but it is not a full terminal emulation (and hence can’t run ncurses programs).
To easily use the debugger, I would like to tweak the Scheme that the “Run” feature starts the application in Terminal.app or iTerm.app instead.
Does anyone know how to achieve this? My first attempts to change the Executable in the “Run” section of the scheme editor to use Terminal.app and use arguments were not successful (but then again, I am not familiar with possible arguments for Terminal.app).
Update: Thanks for pointing to How to run command-line application from the terminal? - this is indeed almost what I am after. The problem is that at least on OS X 10.11, SIP (System Integrity Protection) requires to turn off the "Debug Executable" option (besides, I don't want to debug Terminal.app, but rather my application).
So the remaining question is if it is possible to let the "Run" also start the debugger the debug the built executable (i.e. without manually attaching the debugger after the executable was started).
Related
Given the name of a shortcut in Apple's Shortcuts app, or some other way of identifying a shortcut, how can a native macOS app run it?
This would be the equivalent of executing the following shell command:
shortcuts run "Shortcut name here"
Granted executing a shell command is a possible way of doing this, but I'm hoping that using an API function will be better since they generally allow for better control and error handling. For example, the shell command doesn't provide any easily obtained error code for the calling process when something goes wrong, but rather displays a system notification with the error code.
edit: So far searching online and Apple's docs, as well as looking at the external symbols in Apple's shortcuts command line utility, suggests there is currently no public API for this. If so then then executing a shell command is probably the only way to do this. I'll leave this question open in case this is incorrect or it eventually changes.
I ran into the following issue using Pascal/FPC/Lazarus, but I think it is universal to all Windows .exe files, regardless of the IDE/compiler they are created with:
I created a Windows GUI application and wanted to display some debugging infos in a simple text console. Usually in a Pascal console application Write and WriteLn are used to write to a console/StdOut, but without additional measures in the project configuration this crashes because in a GUI exe (at least if created with Lazarus) a console window does not exist, I get a "file not open" exception.
There are multiple ways in Lazarus (centered around controlling the -WG switch during the build process) to get a console attached "write /writeln" can write text to, this is not the question. My question is, whether support for a console device (StdIn, StdOut, StdErr) is a Windows feature, which is part of the Windows Runtime, probably controlled by some metadata embedded in the exe, which in turn is controlled by this -WG switch, or whether it is a feature of a runtime environment added by a specific development environment, in this case by the Lazarus IDE or a runtime coming with the underlying FPC compiler.
Thnx!
Yes, consoles are generally not used for Windows GUI apps, though you can afaik instantiate some with allocconsole manually. Very early versions of Lazarus did this.
As David says, in general on Windows Outputdebugstring() is used or a logging library.
Technical details: afaik all windows processes (so also console) must actively activate the console, a task typically done by the runtime. The -WG switch suppresses this by setting a special IsConsole boolean variable to false.
The console io initialization is in rtl/win/syswin.inc procedure SysInitStdIO around line 515.
In there you can see that if not IsConsole a dummy file description is made (assignerror), and errors are redirected to message boxes(and might pass by GUI users unnoticed).
I wrote an "emacsinit" file like
/usr/local/Cellar/emacs/24.1/Emacs.app/Contents/MacOS/Emacs --daemon
and drag the file "emacsinit" into the "Login Items".
But it doesn't seem to work. The server doesn't start after system start.
How can I deal with it?
The Login Items scheme likely expects that the launched apps are full app bundles, not just individual shell scripts.
A tool called Platypus can be used to wrap your shell script up as a full application.
Another option is to create an OS X per-user launchd item for Emacs, which is easy if you use an app called Lingon. (Older Lingon versions were free, and will also do the trick.)
For what it's worth, I get all the same advantages with less work by starting the regular Emacs app and then activating the server with the following code:
(require 'server)
(unless (server-running-p)
(server-start))
After that, I can create new text and graphical frames freely using emacsclient.
this is not yet another "I need a console in my GUI app" that has been discussed quite frequently. My situation differs from that.
I have a Windows GUI application, that is run from a command line. Now if you pass wrong parameters to this application, I do not want a popup to appear stating the possible switches, but I want that printed into the console that spawned my process.
I got that far that I can print into the console (call to AttachConsole(...) for parent process) but the problem is my application is not "blocking". As soon as I start it, the command prompt returns, and all output is written into this window (see attached image for illustration).
I played around a bit, created a console app, ran it, and see there, it "blocks", the prompt only re-appears after the app has terminated. Switching my GUI app to /SUBSYSTEM:Console causes strange errors (MSVCRTD.lib(crtexe.obj) : error LNK2019: nonresolved external Symbol "_main" in function "___tmainCRTStartup".)
I have seen the pipe approach with an ".exe" and a ".com" file approach from MSDEV but I find it horrible. Is there a way to solve this prettier?
This is not behaviour that you can change by modifying your application (aside from re-labelling it as already discussed). The command interpreter looks at the subsystem that an executable is labelled with, and decides whether to wait for the application to terminate accordingly. If the executable is labelled as having a GUI, then the command interpreter doesn't wait for it to terminate.
In some command interpreters this is configurable. In JP Software's TCC/LE, for example, one can configure the command interpreter to always wait for applications to terminate, even GUI ones. In Microsoft's CMD, this is not configurable behaviour, however. The Microsoft answer is to use the START command with the /WAIT option.
Once again: This is not the behaviour of your application. There is, apart from relabelling as a TUI program, no programmatic way involving your code to change this.
Maybe write a console-based wrapper app that checks the parameters, prints the error message on bad parameters, and calls/starts up the actual program when the parameters are correct?
I have a testing setup which runs an Application on OS X with a varying set of parameters, if/when the program crashes it's relaunched and continues from where it left off. However when the Application crashes OS X raises the “Application quit unexpectedly” dialog, I'd rather avoid this as it clutters the machine. Is there a way to inhibit this dialog from opening without modifying the source of the Application? If it's of any help in honing solutions the scripting setup is written in Python.
As an example, on Windows I handle the GPF dialog like this:
SEM_NOGPFAULTERRORBOX = 0x0002
ctypes.windll.kernel32.SetErrorMode(SEM_NOGPFAULTERRORBOX);
Ideally there'd be something similar I could use on OS X.
Thanks.
With the developer tools (Xcode, etc.) installed, you get a tool called CrashReporterPrefs. This is basically an interface to some plist file that sets globally how you want crashes handled. Probably not exactly what you're looking for, but if you control the deployment environment it might help.
There must be other options because Google products, like Sketchup, override the default handler and install their own crash reporter. My guess is that they register signal handlers for SIGBUS, SIGSEGV, etc. (see man 2 sigaction) and somehow mask the crash from MacOSX... but I'm speculating here.
I'll let others ask the question on why you can't fix the crash instead. :-)