'>' or '>>' is not working for DocC diagnostic log

Development Swift-DocC
1

Hi, I try to save docc warning diagnostic log in a file.

I move docc bin to project root path, then use this cmd:

./docc convert Sample.docc \
--additional-symbol-graph-dir $symbol_graph_path \
--output-dir ./build/docc \
--diagnostic-level warning >> docc.log

When convert finished, log still output in the terminal. The docc.log is empty.

Is this some way I can save warning log in a file?

Here is my env:
DocC: 88d0fd6
swift-driver version: 1.62.15 Apple Swift version 5.7.2 (swiftlang-5.7.2.135.5 clang-1400.0.29.51)
Target: arm64-apple-macosx13.0
xcrun version 61.

2

The warnings are probably being printed to stderr instead of stdout

try using 2> instead of >

4 Likes
3

If the reason for wanting to save the docc diagnostics to a file is to parse them then I should point out that both the main and the release/5.9 branches of DocC have a built-in option to write the full fidelity diagnostics to a JSON file by passing --diagnostics-file path/to/some-file-name.json. You can check the docc "features.json" file to check if the DocC you're using supports this flag.

I noticed just now that we don't have an OpenAPI spec for the structure of that JSON[1] but the Codable struct definition can be found in DiagnosticFile.swift.

  1. We have one diagnostic OpenAPI spec file but that's for a previous file format that we intend to deprecate in the future. ↩︎

4 Likes
5

That's help.
Thanks!

But I found if i pass --diagnostics-file, The warning log also output in the terminal.
Is that possible --diagnostics-file flag only write the diagnostics to file, not output in the terminal.
It looks like this flag did two things, write json diagnostics and output to terminal.
(But it doesn't matter, I can ignore the log! ^_^ )

6

Yes, the way that the diagnostic file option is currently intended to work specifies output to a file in addition to the output to standard error.

I wasn't sure if it would be more or less confusing for the diagnostic file option to also stop writing diagnostics to standard error but I'd be interested in changing that behavior if there's a consensus on which behavior is less confusing.