fold, fmt, par: get your text in order
============================================
If you happen to read plain text files (e.g., phlog posts), you have
probably noticed that, especially on gopher, the lines of a text file
tend to be wrapped all to a similar length. Some authors are very strict
on the matter, and like all the lines to be "justified" (i.e., all
adjusted to have exactly the same length, by inserting a few spaces to
get the count right). Some other authors (including myself) just do not
allow any line to be longer than a certain amount of characters (in this
case, as you might have noticed, the magic number is 72). But how to
they manage to do that?
Most common editors have a command to format a paragraph ('M-q' in
Emacs, 'gwip' or '{gq}' in vim normal mode, etc.). But obviously,
there are several Unix tools that can help you getting the right
formatting for your files. We are talking of fold(1), fmt(1), and
par(1), so keep reading if you want to know more.
The oldest one is probably `fold(1)` (and it is also the only one to be
defined in the POSIX standard...). It will just break each line to make
it fit a given length in characters (by default, 72, which is indeed a
magic number). Let's see how to wrap the lines of this post at 54
characters:
$ fold -w 54 20190213_fold.txt | head -10
fold, fmt, par: get your text in order
============================================
If you happen to read plain text files (e.g., phlog po
sts), you have
probably noticed that, especially on gopher, the lines
of a text file
tend to be wrapped all to a similar length. Some autho
rs are very strict
on the matter, and like all the lines to be "justified
$
Notice that fold(1) did not really think twice before breaking "posts"
or "authors" across two lines. This is pretty inconvenient, to say the
least. You can actually force fold(1) to break stuff at blank spaces,
using the '-s' option:
$ fold -w 54 -s 20190213_fold.txt |head -10
fold, fmt, par: get your text in order
============================================
If you happen to read plain text files (e.g., phlog
posts), you have
probably noticed that, especially on gopher, the
lines of a text file
tend to be wrapped all to a similar length. Some
authors are very strict
on the matter, and like all the lines to be
$
Nevertheless, the output of fold(1) is still quite off: it breaks lines
at spaces, but it does not "join" broken lines to have a more consistent
formatting. This is where `fmt(1)` jumps in:
$ fmt -w 54 20190213_fold.txt |head -10
fold, fmt, par: get your text in order
============================================
If you happen to read plain text files (e.g., phlog
posts), you have probably noticed that, especially on
gopher, the lines of a text file tend to be wrapped
all to a similar length. Some authors are very strict
on the matter, and like all the lines to be
"justified" (i.e., all adjusted to have exactly the
same length, by inserting a few spaces to get the
$
Now we are talking: fmt(1) seems to be able to to "the right thing"
without much effort, and it has a few other interesting options as well.
Just have a look at the manpage. Simple and clear.
Last but not least, `par(1)` can do whatever fmt(1) and fold(1) can do,
plus much, much more. For instance:
$ par 54 < 20190213_fold.txt | head -10
fold, fmt, par: get your text in order
============================================
If you happen to read plain text files (e.g., phlog
posts), you have probably noticed that, especially on
gopher, the lines of a text file tend to be wrapped
all to a similar length. Some authors are very
strict on the matter, and like all the lines to be
"justified" (i.e., all adjusted to have exactly the
same length, by inserting a few spaces to get the
$
will give more or less the same output as fmt(1). But:
$ par 54j < 20190213_fold.txt | head -10
fold, fmt, par: get your text in order
============================================
If you happen to read plain text files (e.g., phlog
posts), you have probably noticed that, especially on
gopher, the lines of a text file tend to be wrapped
all to a similar length. Some authors are very
strict on the matter, and like all the lines to be
"justified" (i.e., all adjusted to have exactly the
same length, by inserting a few spaces to get the
$
will additionally "justify" your lines to the prescribed width, while:
something like:
$ head file.h
*
* include/linux/memory.h - generic memory definition
*
* This is mainly for topological representation. We define the
* basic "struct memory_block" here, which can be embedded in per-arch
* definitions or NUMA information.
*
* Basic handling of the devices is done in drivers/base/memory.c
* and system devices are handled in drivers/base/sys.c.
*
$
can be easily transformed into:
$ par 40j < file.h
*
* include/linux/memory.h - generic
*memory definition
*
* This is mainly for topological
* representation. We define the basic
* "struct memory_block" here, which can
* be embedded in per-arch definitions
* or NUMA information.
*
* Basic handling of the devices is
* done in drivers/base/memory.c and
* system devices are handled in
* drivers/base/sys.c.
*
* Memory block are exported via
* sysfs in the class/memory/devices/
* directory.
*
*
$
Pretty neat, right? [1]
-+-+-+-
fold(1) appeared in BSD1 (1978-1979)
fmt(1) appeared in BSD1 (1978-1979)
par(1) was developed by Adam Costello in 1993, as a replacement for
fmt(1)
-+-+-+-
[1] To be honest, par is not the typical example of a unix tool that
"does exactly one thing", but it certainly "does it very well" all the
things it does. The author of par(1) felt the need to apologise in the
manpage about the style of his code and documentation, but I still think
par(1) is an awesome tool nevertheless.
