[DTrace-devel] [PATCH 09/14] man: drop blank lines

Kris Van Hees kris.van.hees at oracle.com
Fri Oct 25 02:50:19 UTC 2024


On Thu, Oct 24, 2024 at 12:37:53PM +0100, Nick Alcock wrote:
> They don't do what you might expect in troff: a leading . is preferable.
> 
> Signed-off-by: Nick Alcock <nick.alcock at oracle.com>

Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>

> ---
>  cmd/dtrace.8 | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/cmd/dtrace.8 b/cmd/dtrace.8
> index a53632949e72..0639db2136a7 100644
> --- a/cmd/dtrace.8
> +++ b/cmd/dtrace.8
> @@ -179,15 +179,15 @@ Print libdtrace debugging output on standard error.
>  Print CTF type library debugging output on standard error.
>  .IP DTRACE_OPT_*
>  Set a given DTrace option.
> -
> +.
>  Options set this way are overridden both by options specified via \fB\-x\fR on the command line, and by \fBsetopt\fR statements.
> -
> +.
>  .SH SEE ALSO
>  .BR cpp (1),
>  .BR ssh (1)
>  .LP
>  .I Oracle Linux DTrace Guide
> -
> +.
>  .SH USAGE
>  .LP
>  When using the \fB\-p\fR flag, \fBdtrace\fR stops the target processes while it is inspecting them and reporting results. A process can do nothing while it is stopped. This means that, if, for example, the X server is inspected by \fBdtrace\fR running in a window under the X server's control, the whole window system can become deadlocked, because the \fBdtrace\fR tool would be attempting to display its results to a window that cannot be refreshed. In such a case, logging in from another system using \fBssh\fR(1) and killing the offending \fBdtrace\fR tool clears the deadlock.
> -- 
> 2.46.0.278.g36e3a12567
> 



More information about the DTrace-devel mailing list