[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