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.