sensors-detect.8: editorial fixes

Submitted by Bjarni Ingi Gislason <bjarniig@simnet.is> via the Debian
BTS, bug #1051123.

diff --git a/prog/detect/sensors-detect.8 b/prog/detect/sensors-detect.8
index 6976d74fad6b4b6f80947dabdf51452dc1b600c9..8c789f66d7db6ace553a6707497200c97cd972c1 100644 (file)
--- a/prog/detect/sensors-detect.8
+++ b/prog/detect/sensors-detect.8
@@ -1,19 +1,21 @@
 .TH SENSORS-DETECT 8 "September 2013" "lm-sensors 3"
 .SH NAME
 sensors-detect \- detect hardware monitoring chips
-
+.
 .SH SYNOPSIS
-.B sensors-detect [
-.I --auto
-.B ]
-
+.BR sensors-detect " ["
+.BR \-\-auto " ]"
+.
 .SH DESCRIPTION
-sensors-detect is an interactive program that will walk you through the
+.B sensors-detect
+is an interactive program that will walk you through the
 process of scanning your system for various hardware monitoring chips,
-or sensors, supported by libsensors(3), or more generally by the lm_sensors
-tool suite.
+or sensors, supported by
+.BR libsensors (3),
+or more generally by the lm_sensors tool suite.
 
-sensors-detect will look for the following devices, in order:
+.B sensors-detect
+will look for the following devices, in order:
 .IP \(bu
 Sensors embedded in CPUs, south bridges and memory controllers.
 .IP \(bu
@@ -24,40 +26,57 @@ Hardware monitoring chips accessed through ISA I/O ports.
 Hardware monitoring chips reachable over the SMBus or more generally
 any I2C bus on your system.
 .PP
-As the last two detection steps can cause trouble on some systems, they
-are normally not attempted if the second detection step led to the
-discovery of a Super I/O chip with complete hardware monitoring features.
-However, the user is always free to ask for all detection steps if so is
-his/her wish. This can be useful if a given system has more than one
-hardware monitoring chip. Some vendors are known to do this, most notably
-Asus and Tyan.
-
+As the last two detection steps can cause trouble on some systems,
+they are normally not attempted
+if the second detection step led to the discovery of a Super I/O chip
+with complete hardware monitoring features.
+However,
+the user is always free to ask for all detection steps
+if so is his/her wish.
+This can be useful
+if a given system has more than one hardware monitoring chip.
+Some vendors are known to do this,
+most notably Asus and Tyan.
+.
 .SH OPTIONS
-.IP "--auto"
-Run in automatic, non-interactive mode. Assume default answers to all
-questions. Note that this isn't necessarily safe as the internal logic may
-lead to potentially dangerous probes being attempted. See the WARNING section
-below.
-.IP "--stat"
+.IP \-\-auto
+Run in automatic, non-interactive mode.
+Assume default answers to all questions.
+Note that this isn't necessarily safe
+as the internal logic may lead to potentially dangerous probes being attempted.
+See the WARNING section below.
+.IP \-\-stat
 Display I2C address statistics.
-
+.
 .SH WARNING
-sensors-detect needs to access the hardware for most of the chip detections.
-By definition, it doesn't know which chips are there before it manages to
-identify them. This means that it can access chips in a way these chips do
-not like, causing problems ranging from SMBus lockup to permanent hardware
-damage (a rare case, thankfully.)
-
-The authors made their best to make the detection as safe as possible, and
-it turns out to work just fine in most cases, however it is impossible to
-guarantee that sensors-detect will not lock or kill a specific system. So,
-as a rule of thumb, you should not run sensors-detect on production servers,
-and you should not run sensors-detect if can't afford replacing a random
-part of your system. Also, it is recommended to not force a detection step
-which would have been skipped by default, unless you know what you are doing.
+.B sensors-detect
+needs to access the hardware for most of the chip detections.
+By definition,
+it doesn't know which chips are there
+before it manages to identify them.
+This means that it can access chips in a way these chips do not like,
+causing problems ranging from SMBus lockup to permanent hardware damage
+(a rare case, thankfully.)
 
+The authors made their best to make the detection as safe as possible,
+and it turns out to work just fine in most cases,
+however it is impossible to guarantee that
+.B sensors-detect
+will not lock or kill a specific system.
+So, as a rule of thumb,
+you should not run
+.B sensors-detect
+on production servers,
+and you should not run
+.B sensors-detect
+if you can't afford replacing a random part of your system.
+Also, it is recommended to not force a detection step
+which would have been skipped by default,
+unless you know what you are doing.
+.
 .SH SEE ALSO
-sensors(1), libsensors(3)
-
+.BR sensors (1),
+.BR libsensors (3)
+.
 .SH AUTHOR
 Frodo Looijaard and Jean Delvare