Currently the output of the cct utility is different between radians
and degrees (as expected by cct), because of a bug in cct:

$ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad
  1.0000000000    2.0000000000        0.0000        0.0000

$ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=deg
       1.0000         2.0000        0.0000        0.0000

The arguments to the printf format string are as follows:

 * radians: width 14, precision 10
 * degrees: width 13, precision  4 (this is by mistake. bug!)

After the suggested fix has been applied, output will be the same for
both radians and degrees:

$ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad
  1.0000000000    2.0000000000        0.0000        0.0000

$ printf "1 2\n" | cct -z 0 -t 0 +proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=deg
  1.0000000000    2.0000000000        0.0000        0.0000

The cause of the bug is that cct does test if it "has radians to output",
but "neglects" to test if it "has degrees to output", resulting in using
different arguments to the printf format string in the latter case.

The fix makes cct test if it "has either radians or degrees to output".

As result of a modification in logging (adding a line feed),
many changes had to be made in different places of cct.cpp.
However, one missed the line feed in input to cct.
As result of missing this, the output from cct showed a
superfluous empty line after each output line, but only if
the corresponding input line ended with comment.
Replacing the LF in the "comment" string (present if the
input line ended with comment) by a null character ('\0')
solves this issue.

Modification in logging?
https://github.com/OSGeo/PROJ/commit/37da5e243191c04607597f6b8a77acfa017a5c99
( cct: revise end-of-line handling in logging, and always output debug )

See also:
https://github.com/OSGeo/PROJ/issues/1677
( cct outputs excessive whitespace comments are included in input data )

This is needed when working with pipes, when stdout is not an interactive terminal,
and thus the behaviour is to have it buffered as a regular file, whereas with
an interactive terminal, each newline character causes an implicit flush.