3

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.

ylluminate
  • 12,102
  • 17
  • 78
  • 152

2 Answers2

1

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.

slightly_toasted
  • 335
  • 5
  • 18
  • That's really not good and is unfortunate. Sounds like `dtrace` and other *trace functions are our only real options to capture this information and it may be necessary in those cases to relax system security or to insert a kernel extension. Hmm. – ylluminate Jun 11 '20 at 04:40
0

With regards to /usr/bin/open, looking at it's help (-h), it looks like it should be possible using the --stdin and --stdout args:

⇒ /usr/bin/open -h
Usage: open [-e] [-t] [-f] [-W] [-R] [-n] [-g] [-h] [-s <partial SDK name>][-b <bundle identifier>] [-a <application>] [-u URL] [filenames] [--args arguments]
Help: Open opens files from a shell.
      By default, opens each file using the default application for that file.
      If the file is in the form of a URL, the file will be opened as a URL.
Options:

..snip..

      -i, --stdin  PATH     Launches the application with stdin connected to PATH; defaults to /dev/null
      -o, --stdout PATH     Launches the application with /dev/stdout connected to PATH;
          --stderr PATH     Launches the application with /dev/stderr connected to PATH to
          --env    VAR      Add an enviroment variable to the launched process, where VAR is formatted AAA=foo or just AAA for a null string value.
Glenn 'devalias' Grant
  • 1,928
  • 1
  • 21
  • 33