Formatting log output for unambiguous parsing

Question

DMR cautions us to assume that any program's output may be used as another program's input.
Unfortunately, many Unix tools ignore this advice. Logging commands are particularly egregious
offenders, given that the enormous size of log files all but requires mechanical interpretation.
Log formats which may be perfectly suitable for human interpretation can cause real problems for
parsing scripts. Let's assume, for instance, that you want to log all open(2) calls, including the full
path names of the files being opened. How do you write the file names such that all possible byte
sequences can be encoded (and later, parsed) without error?
With the possible exception of nulls, no character is off-limits. Unix file names may include spaces,
tabs, quote marks, newlines, and what have you. This defeats any attempt to "quote" the names.
Other strategies include (a) specially encoding certain characters (e.g., "<" in HTML and XML use),
(b) encoding all characters (e.g., BinHex format), and use of counted strings.
Looking at the SDTG, I see no way to do any of these. The %x and %X formats do not seem to be
defined for string values, so I can't just print the string as a sequence of hex digit pairs. Nor can I loop
over the string, printing the characters one at a time. Is there something (e.g., a translator or some
other form of conversion function) that I can use to resolve this problem?

Answer 1

We should be able to get this implemented in thenear future.
Great! I'm unfamiliar, however, with Sun's patch and
upgrade mechanisms these days (I moved from
SunOS to FreeBSD, later adding Mac OS X). Could you
give me an idea of what to expect, both in
this pre-release period and after Solaris 10 ships? Solaris 10 will become generally available at the end of this calendar year. Prior to GA,
we are making a continuous series of beta releases available through Solaris Express,
about one per monthor so. After GA, like all Solaris releases, we issue patches when
there are functionality problems to be corrected, as well as Quarterly Updates which
batch together some add-ons with all the latest patches. In the case of a small DTrace
enhancement, we'll try to get it fixed before Solaris 10 GA, which means it will be fixed
in the final release of Solaris 10, and might show up in a Solaris Express download
in the coming months. Bryan, Adam, and I will also post here about any new DTrace
features of interest that show up in a particular Solaris Express download.
-Mike