With the application Utilities/Console.app, I can see the console output of applications.
Is there a way to access this log from another application?
To be more specific: I am writing a crashhandler for my application and I want that it attaches the console output to the crash information.
Ah, just found out that there is the file /var/log/system.log which contains those information.
/var/log/system.log was not really a solution because the output didn't immediatly appeared there (which was a big problem because how should my crash handler know that everything is complete there), also the grepping of the related messages was very hackish and then, when I started several instances of the application, I didn't really know about the correct related output (unless I knew the pid but even then, also the pid is not unique).
Know, a solution I am very happy with, is that the application itself is keeping track about all the console output. It is doing that by forking itself and piping its output to the fork and emulating the tee tool there, where one output is a special log file. When it crashes, it sends the filename of the logfile to the crashhandler.
If you are interested, look at the OpenLieroX source code ( http://sourceforge.net/projects/openlierox ).
Related
In macOS one can normally get some appreciable console / shell output by executing a process by executing it's binary directly in the Terminal via:
/Applications/SOME_APPLICATION.app/Contents/MacOS/SOME_APPLICATION
This can be very useful from time to time for debugging and catching errors that occur. With the introduction of Catalina (10.15), direct execution of applications in this fashion is discouraged from scripts, etc. and causes various problems, ultimately requiring the use of /usr/bin/open.
How can we redirect STDERR / STDOUT of a process after it's been started?
There has been some discussion on this topic previously for Linux, but it's not clear as to whether some of this will work out for macOS now.
reptyr would be fantastic if it could be repurposed for macOS since it already works mostly for FreeBSD.
This answer is from 2013 but is mostly still relevant.
Prior to Mountain Lion, all processes managed by launchd, including
regular applications, had their stdout and stderr file descriptors
forwarded to the system log. In Mountain Lion and above, stdout and
stderr go nowhere for launchd managed applications. Only messages
explicitly sent to the system log will end up there.
If you're writing an application and would like some output to show up
in the console, then adopt an API built on syslog(3) or asl(3)
instead. NSLog is one such API, and it has the advantage of logging to
stderr too so you can easily see your output no matter how you've
launched your application. If you'd like that functionality but want
to use asl or syslog directly then you'll want to look in to the
ASL_OPT_STDERR option to asl_open, and the LOG_PERROR option to
openlog respectively.
Basically, when you double-click an app (same as /usr/bin/open) there is no stdout/stderr. The dev is expected to send any relevant output/errors to the available logging APIs such as NSLog.
I've got a Windows CLI EXE that prints to the console when I run it.
This is not a program I can modify.
I wrapped this in a gradle Exec task, and it clearly is running, but nothing is getting printed to the screen. I had not configured anything special with the output.
I ran the program directly again but used 1> and 2> to redirect stdout and stderr to files.
Because this program takes 3 hours to run I hit Ctrl-C after a while and opened the redirect files.
None of the usual output was in the files.
Could it be using backspace or some other mechanism to prevent output from capture? The output does not clear on the actual console. Any ideas would be helpful.
I found another program by the same author that does not take as long, so I was able to let it finish.
The program does in fact write to stdout, but it doesn't flush until the very end. Which would be 3 hours for the program in the question! I would have thought that flushing would impact the console as well as a redirect stream, but it appears to only impact redirects. This makes sense if you wanted to have an animated progress spinner or something like that. Since I can't update the program code.
It looks like I'm just stuck with no progress updates.
I have an ffmpeg.exe process that appears to be hung - it hasn't done anything for several days. It was started by exec() in PHP, so is running in the background and has no window.
I would like to know what caused it to stop/hang.
Is there anyway to get what it has written to stdout?
I don't think I understand you correctly, but I'll try.
If you wanna see its output, you can hook its output functions via IAT/inline hooking and redirect it to a file or something.
However, I think you just wanna see what it is doing. In that case I suggest you to use "Procmon" from the "Sysinternals Suit".
Earlier, I could read all stdout/stderr data from applications in Console.app. Since a while, this is not the case anymore (NSLog data is still there, though). I'm on 10.8 now.
There was an earlier similar question from 2010 which doesn't seem up-to-date anymore.
On SU, there is also a similar question which wasn't yet answered.
Has that been changed, i.e. stdout is not supposed to be logged anymore? Or is something broken on my system (from the old SU question, it sounded like that might be the case - although without being helpful)?
Can I somehow change it back?
Prior to Mountain Lion, all processes managed by launchd, including regular applications, had their stdout and stderr file descriptors forwarded to the system log. In Mountain Lion and above, stdout and stderr go nowhere for launchd managed applications. Only messages explicitly sent to the system log will end up there.
If you're writing an application and would like some output to show up in the console, then adopt an API built on syslog(3) or asl(3) instead. NSLog is one such API, and it has the advantage of logging to stderr too so you can easily see your output no matter how you've launched your application. If you'd like that functionality but want to use asl or syslog directly then you'll want to look in to the ASL_OPT_STDERR option to asl_open, and the LOG_PERROR option to openlog respectively.
If you have an old app and want to see stdout or stderr, open the app from Terminal. You can wind your way to the executable and open it from the command line, like in the normal, old world: type the program name. Then the messages will appear on the terminal.
This is not a repudiation of any of the other, better suggestions. It is just a way to get the output without altering the (old) program.
Background: We develop win32 applications, and use the "Thompson Toolkit" on windows to give us a unix-like shell that we use as our command-line.
We have a GUI program (with a WinMain and message loop) that we want to write to the console, but printf and so on don't work, even when we launch the program from the console. How can we write to the console from a GUI program? We need to print text there so that an automated build system can display error messages and so on.
Thanks.
In short, you need to attach a console. For details and ready to use code, see http://www.codeproject.com/KB/dialog/ConsoleAdapter.aspx.
Basicly you have to create a console by your self with AllocConsole, AttachConsole. After that you have to get standard handles with GetStdHandle and "associates a C run-time file descriptor with an existing operating-system file handle" with help of _open_osfhandle.
The returned handle can be used to overwrite crt stdin and stdout. After that all crt methods like printf should work.
Instead of logging to the console, log to a file and then track the file with a separate gui application. This keeps the console uncluttered and gives you a more persistent record of your log, which occasionally is extremely useful. There are various libraries which will do most of this for you, or you can keep it simple and just do it yourself.
somewhere in the Visual Studio Project Settings you can switch on having a console, assuming you are using VS. (Can't say where because I currently don't have it)