iconv.1, locale.1, localedef.1, memusage.1, memusagestat.1, mtrace.1, pldd.1, sprof.1, time.1, iconvconfig.8, ld.so.8, ldconfig.8, sln.8: Formatting fix: replace blank lines with .PP/.IP

Blank lines shouldn't generally appear in *roff source (other
than in code examples), since they create large vertical
spaces between text blocks.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

man1/iconv.1

@@ -64,14 +64,14 @@ for input characters.
 Use
 .I to-encoding
 for output characters.
-
+.IP
 If the string
 .BR //IGNORE
 is appended to
 .IR to-encoding ,
 characters that cannot be converted are discarded and an error is
 printed after conversion.
-
+.IP
 If the string
 .BR //TRANSLIT
 is appended to
@@ -180,7 +180,7 @@ Usual system gconv module configuration cache.
 POSIX.1-2001.
 .SH EXAMPLE
 Convert text from the ISO 8859-15 character encoding to UTF-8:
-
+.PP
 .in +4n
 .nf
 $ \fBiconv \-f ISO\-8859\-15 \-t UTF\-8 < input.txt > output.txt\fP
@@ -189,7 +189,7 @@ $ \fBiconv \-f ISO\-8859\-15 \-t UTF\-8 < input.txt > output.txt\fP
 .PP
 The next example converts from UTF-8 to ASCII, transliterating when
 possible:
-
+.PP
 .in +4n
 .nf
 $ \fBecho abc ß α € àḃç | iconv \-f UTF\-8 \-t ASCII//TRANSLIT\fP

man1/locale.1

@@ -37,7 +37,7 @@ The
 .B locale
 command displays information about the current locale, or all locales,
 on standard output.
-
+.PP
 When invoked without arguments,
 .B locale
 displays the current locale settings for each locale category (see
@@ -47,7 +47,7 @@ based on the settings of the environment variables that control the locale
 .BR locale (7)).
 Values for variables set in the environment are printed without double
 quotes, implied values are printed with double quotes.
-
+.PP
 If either the
 .B \-a
 or the
@@ -94,11 +94,11 @@ When arguments are supplied, the following options are meaningful:
 For a category name argument,
 write the name of the locale category
 on a separate line preceding the list of keyword values for that category.
-
+.IP
 For a keyword name argument,
 write the name of the locale category for this keyword
 on a separate line preceding the keyword value.
-
+.IP
 This option improves readability when multiple name arguments are specified.
 It can be combined with the
 .B \-k
@@ -108,7 +108,7 @@ option.
 For each keyword whose value is being displayed,
 include also the name of that keyword,
 so that the output has the format:
-
+.IP
     \fIkeyword\fP="\fIvalue\fP"
 .PP
 The
@@ -178,7 +178,7 @@ int_select="11"
 int_prefix="1"
 telephone\-codeset="UTF\-8"
 .fi
-
+.PP
 The following example compiles a custom locale from the
 .I ./wrk
 directory with the
@@ -193,7 +193,7 @@ and
 .B LANG
 in the shell profile file so that the custom locale will be used in the
 subsequent user sessions:
-
+.PP
 .nf
 $ \fBmkdir -p $HOME/.locale\fP
 $ \fBI18NPATH=./wrk/ localedef -f UTF-8 -i fi_SE $HOME/.locale/fi_SE.UTF-8\fP

man1/localedef.1

@@ -72,7 +72,7 @@ locale functions in the C library
 .BR localeconv (3),
 etc.), and places the output in
 .IR outputpath .
-
+.PP
 The
 .I outputpath
 argument is interpreted as follows:

man1/memusage.1

@@ -119,7 +119,7 @@ For
 .BR realloc (3),
 the additional field "free" shows reallocations that
 caused a block to be freed (i.e., the reallocated size was 0).
-
+.PP
 The "realloc/total memory" of the table output by
 .B memusage
 does not reflect cases where
@@ -208,7 +208,7 @@ reallocating the memory in smaller blocks that return to zero.
 After compiling the program and running the following commands,
 a graph of the memory usage of the program can be found in the file
 .IR memusage.png :
-
+.PP
 .in +4n
 .nf
 $ \fBmemusage --data=memusage.dat ./a.out\fP

man1/memusagestat.1

@@ -36,7 +36,7 @@ that file is generated via the
 .IR --data )
 option of
 .BR memusage (1).
-
+.PP
 The red line in the graph shows the heap usage (allocated memory)
 and the green line shows the stack usage.
 The x-scale is either the number of memory-handling function calls or

man1/mtrace.1

@@ -41,7 +41,7 @@ for problem locations
 (assuming that
 .I binary
 was compiled with debugging information).
-
+.PP
 For more information about the
 .BR mtrace (3)
 function and

man1/pldd.1

@@ -79,7 +79,7 @@ lsof \-p PID
 .PP
 also shows output that includes the dynamic shared objects
 that are linked into a process.
-
+.PP
 The
 .BR gdb (1)
 .I "info shared"

man1/sprof.1

@@ -82,7 +82,7 @@ The following example demonstrates the use of
 The example consists of a main program that calls two functions
 in a shared object.
 First, the code of the main program:
-
+.PP
 .in +4n
 .nf
 $ \fBcat prog.c\fP
@@ -107,7 +107,7 @@ and
 .IR x2()
 are defined in the following source file that is used to
 construct the shared object:
-
+.PP
 .in +4n
 .nf
 $ \fBcat libdemo.c\fP
@@ -154,7 +154,7 @@ Now we construct the shared object with the real name
 .IR libdemo.so.1.0.1 ,
 and the soname
 .IR libdemo.so.1 :
-
+.PP
 .in +4n
 .nf
 $ \fBcc \-g \-fPIC \-shared \-Wl,\-soname,libdemo.so.1 \e\fP
@@ -164,7 +164,7 @@ $ \fBcc \-g \-fPIC \-shared \-Wl,\-soname,libdemo.so.1 \e\fP
 .PP
 Then we construct symbolic links for the library soname and
 the library linker name:
-
+.PP
 .in +4n
 .nf
 $ \fBln \-sf libdemo.so.1.0.1 libdemo.so.1\fP
@@ -174,7 +174,7 @@ $ \fBln \-sf libdemo.so.1 libdemo.so\fP
 .PP
 Next, we compile the main program, linking it against the shared object,
 and then list the dynamic dependencies of the program:
-
+.PP
 .in +4n
 .nf
 $ \fBcc \-g \-o prog prog.c \-L. \-ldemo\fP
@@ -190,7 +190,7 @@ In order to get profiling information for the shared object,
 we define the environment variable
 .BR LD_PROFILE
 with the soname of the library:
-
+.PP
 .in +4n
 .nf
 $ \fBexport LD_PROFILE=libdemo.so.1\fP
@@ -201,7 +201,7 @@ We then define the environment variable
 .BR LD_PROFILE_OUTPUT
 with the pathname of the directory where profile output should be written,
 and create that directory if it does not exist already:
-
+.PP
 .in +4n
 .nf
 $ \fBexport LD_PROFILE_OUTPUT=$(pwd)/prof_data\fP
@@ -214,7 +214,7 @@ causes profiling output to be
 .I appended
 to the output file if it already exists,
 so we ensure that there is no preexisting profiling data:
-
+.PP
 .in +4n
 .nf
 $ \fBrm \-f $LD_PROFILE_OUTPUT/$LD_PROFILE.profile\fP
@@ -224,7 +224,7 @@ $ \fBrm \-f $LD_PROFILE_OUTPUT/$LD_PROFILE.profile\fP
 We then run the program to produce the profiling output,
 which is written to a file in the directory specified in
 .BR LD_PROFILE_OUTPUT :
-
+.PP
 .in +4n
 .nf
 $ \fBLD_LIBRARY_PATH=. ./prog\fP
@@ -236,7 +236,7 @@ libdemo.so.1.profile
 We then use the
 .BR "sprof \-p"
 option to generate a flat profile with counts and ticks:
-
+.PP
 .in +4n
 .nf
 $ \fBsprof \-p libdemo.so.1 $LD_PROFILE_OUTPUT/libdemo.so.1.profile\fP
@@ -255,7 +255,7 @@ Each sample counts as 0.01 seconds.
 The
 .BR "sprof \-q"
 option generates a call graph:
-
+.PP
 .in +4n
 .nf
 $ \fBsprof \-q libdemo.so.1 $LD_PROFILE_OUTPUT/libdemo.so.1.profile\fP
@@ -286,7 +286,7 @@ are outside of the profiled object (in this example, these are instances of
 The
 .BR "sprof \-c"
 option generates a list of call pairs and the number of their occurrences:
-
+.PP
 .in +4n
 .nf
 $ \fBsprof \-c libdemo.so.1 $LD_PROFILE_OUTPUT/libdemo.so.1.profile\fP

man1/time.1

@@ -41,7 +41,7 @@ values in a
 .I "struct tms"
 as returned by
 .BR times (2)).
-
+.PP
 Note: some shells (e.g.,
 .BR bash (1))
 have a built-in

man8/iconvconfig.8

@@ -42,12 +42,12 @@ Loading and parsing such a configuration file would slow down
 programs that use
 .BR iconv (3),
 so a caching mechanism is employed.
-
+.PP
 The
 .B iconvconfig
 program reads iconv module configuration files and writes
 a fast-loading gconv module configuration cache file.
-
+.PP
 In addition to the system provided gconv modules, the user can specify
 custom gconv module directories with the environment variable
 .BR GCONV_PATH .

man8/ld.so.8

@@ -110,9 +110,9 @@ the directory containing the program or shared object.
 Thus, an application located in
 .I somedir/app
 could be compiled with
-
+.IP
     gcc \-Wl,\-rpath,\(aq$ORIGIN/../lib\(aq
-
+.IP
 so that it finds an associated shared object in
 .I somedir/lib
 no matter where
@@ -229,7 +229,7 @@ At run time,
 the dynamic linker determines the ABI version of the running kernel and
 will reject loading shared objects that specify minimum ABI versions
 that exceed that ABI version.
-
+.IP
 .BR LD_ASSUME_KERNEL
 can be used to
 cause the dynamic linker to assume that it is running on a system with
@@ -238,20 +238,20 @@ For example, the following command line causes the
 dynamic linker to assume it is running on Linux 2.2.5 when loading
 the shared objects required by
 .IR myprog :
-
+.IP
 .in +4n
 .nf
 $ \fBLD_ASSUME_KERNEL=2.2.5 ./myprog\fP
 .fi
 .in
-
+.IP
 On systems that provide multiple versions of a shared object
 (in different directories in the search path) that have
 different minimum kernel ABI version requirements,
 .BR LD_ASSUME_KERNEL
 can be used to select the version of the object that is used
 (dependent on the directory search order).
-
+.IP
 Historically, the most common use of the
 .BR LD_ASSUME_KERNEL
 feature was to manually select the older
@@ -275,9 +275,9 @@ The items in the list are separated by either colons or semicolons.
 Similar to the
 .B PATH
 environment variable.
-
+.IP
 This variable is ignored in secure-execution mode.
-
+.IP
 Within the pathnames specified in
 .BR LD_LIBRARY_PATH ,
 the dynamic linker expands the tokens
@@ -313,13 +313,13 @@ objects to be loaded before all others.
 The items of the list can be separated by spaces or colons.
 This can be used to selectively override functions in other shared objects.
 The objects are searched for using the rules given under DESCRIPTION.
-
+.IP
 In secure-execution mode,
 preload pathnames containing slashes are ignored.
 Furthermore, shared objects are preloaded only
 from the standard search directories and only
 if they have set-user-ID mode bit enabled (which is not typical).
-
+.IP
 Within the names specified in the
 .BR LD_PRELOAD
 list, the dynamic linker understands the tokens
@@ -465,14 +465,14 @@ If
 .B LD_DEBUG_OUTPUT
 is defined, then output is written to the pathname specified by its value,
 with the suffix "." (dot) followed by the process ID appended to the pathname.
-
+.IP
 .B LD_DEBUG_OUTPUT
 is ignored in secure-execution mode.
 .TP
 .BR LD_DYNAMIC_WEAK " (since glibc 2.1.91)"
 By default, when searching shared libraries to resolve a symbol reference,
 the dynamic linker will resolve to the first definition it finds.
-
+.IP
 Old glibc versions (before 2.2), provided a different behavior:
 if the linker found a symbol that was weak,
 it would remember that symbol and
@@ -481,7 +481,7 @@ If it subsequently found a strong definition of the same symbol,
 then it would instead use that definition.
 (If no further symbol was found,
 then the dynamic linker would use the weak symbol that it initially found.)
-
+.IP
 The old glibc behavior was nonstandard.
 (Standard practice is that the distinction between
 weak and strong symbols should have effect only at static link time.)
@@ -497,7 +497,7 @@ In glibc 2.2,
 the dynamic linker was modified to provide the current behavior
 (which was the behavior that was provided by most other implementations
 at that time).
-
+.IP
 Defining the
 .B LD_DYNAMIC_WEAK
 environment variable (with any value) provides
@@ -507,7 +507,7 @@ a strong symbol subsequently discovered in another shared library.
 (Note that even when this variable is set,
 a strong symbol in a shared library will not override
 a weak definition of the same symbol in the main program.)
-
+.IP
 Since glibc 2.3.4,
 .B LD_DYNAMIC_WEAK
 is ignored in secure-execution mode.
@@ -519,7 +519,7 @@ Mask for hardware capabilities.
 Path where the binary is found.
 .\" Used only if $ORIGIN can't be determined by normal means
 .\" (from the origin path saved at load time, or from /proc/self/exe)?
-
+.IP
 Since glibc 2.4,
 .B LD_ORIGIN_PATH
 is ignored in secure-execution mode.
@@ -545,7 +545,7 @@ The name of a (single) shared object to be profiled,
 specified either as a pathname or a soname.
 Profiling output is appended to the file whose name is:
 "\fI$LD_PROFILE_OUTPUT\fP/\fI$LD_PROFILE\fP.profile".
-
+.IP
 Since glibc 2.2.5,
 .BR LD_PROFILE
 is ignored in secure-execution mode.
@@ -557,7 +557,7 @@ output should be written.
 If this variable is not defined, or is defined as an empty string,
 then the default is
 .IR /var/tmp .
-
+.IP
 .B LD_PROFILE_OUTPUT
 is ignored in secure-execution mode; instead
 .IR /var/profile
@@ -571,7 +571,7 @@ is also ignored in secure-execution mode.)
 If this environment variable is defined (with any value),
 show the auxiliary array passed up from the kernel (see also
 .BR getauxval (3)).
-
+.IP
 Since glibc 2.3.4,
 .B LD_SHOW_AUXV
 is ignored in secure-execution mode.
@@ -604,7 +604,7 @@ If
 .B LD_USE_LOAD_BIAS
 is defined with the value 0,
 neither executables nor PIEs will honor the base addresses.
-
+.IP
 Since glibc 2.3.3, this variable is ignored in secure-execution mode.
 .TP
 .BR LD_VERBOSE " (since glibc 2.1)"
@@ -628,7 +628,7 @@ will first try to map executable pages using the
 .BR MAP_32BIT
 flag, and fall back to mapping without that flag if that attempt fails.
 NB: MAP_32BIT will map to the low 2GB (not 4GB) of the address space.
-
+.IP
 Because
 .B MAP_32BIT
 reduces the address range available for address space layout

man8/ldconfig.8

@@ -56,7 +56,7 @@ are the trusted directories for 32-bit libraries, while
 and
 .IR /usr/lib64
 are used for 64-bit libraries).
-
+.PP
 The cache is used by the run-time linker,
 .I ld.so
 or

man8/sln.8

@@ -39,13 +39,13 @@ program, it is statically linked.
 This means that if for some reason the dynamic linker is not working,
 .BR sln
 can be used to make symbolic links to dynamic libraries.
-
+.PP
 The command line has two forms.
 In the first form, it creates
 .I dest
 as a new symbolic link to
 .IR source .
-
+.PP
 In the second form,
 .I filelist
 is a list of space-separated pathname pairs,
@@ -53,7 +53,7 @@ and the effect is as if
 .BR sln
 was executed once for each line of the file,
 with the two pathnames as the arguments.
-
+.PP
 The
 .B sln
 program supports no command-line options.