article-katolaz-formatting-paragraphs.mw - tgtimes - The Gopher Times | |
git clone git://bitreich.org/tgtimes git://enlrupgkhuxnvlhsf6lc3fziv5h2hhfrinws… | |
Log | |
Files | |
Refs | |
Tags | |
README | |
--- | |
article-katolaz-formatting-paragraphs.mw (6147B) | |
--- | |
1 .SH katolaz | |
2 fold, fmt, par: get your text in order | |
3 .2C 19v | |
4 . | |
5 .PP | |
6 If you happen to read plain text files (e.g., phlog posts), you have | |
7 probably noticed that, especially on gopher, the lines of a text file | |
8 tend to be wrapped all to a similar length. Some authors are very strict | |
9 on the matter, and like all the lines to be "justified" (i.e., all | |
10 adjusted to have exactly the same length, by inserting a few spaces to | |
11 get the count right). Some other authors (including myself) just do not | |
12 allow any line to be longer than a certain amount of characters (in this | |
13 case, as you might have noticed, the magic number is 72). But how to | |
14 they manage to do that? | |
15 . | |
16 .PP | |
17 Most common editors have a command to format a paragraph ('M-q' in | |
18 Emacs, 'gwip' or '{gq}' in vim normal mode, etc.). But obviously, | |
19 there are several Unix tools that can help you getting the right | |
20 formatting for your files. We are talking of fold(1), fmt(1), and | |
21 par(1), so keep reading if you want to know more. | |
22 . | |
23 .PP | |
24 The oldest one is probably fold(1) (and it is also the only one to be | |
25 defined in the POSIX standard...). It will just break each line to make | |
26 it fit a given length in characters (by default, 72, which is indeed a | |
27 magic number). Let's see how to wrap the lines of this post at 54 | |
28 characters: | |
29 . | |
30 .1C | |
31 .DS | |
32 $ fold -w 54 20190213_fold.txt | head -10 | |
33 fold, fmt, par: get your text in order | |
34 ============================================ | |
35 If you happen to read plain text files (e.g., phlog po | |
36 sts), you have | |
37 probably noticed that, especially on gopher, the lines | |
38 of a text file | |
39 tend to be wrapped all to a similar length. Some autho | |
40 rs are very strict | |
41 on the matter, and like all the lines to be "justified | |
42 $ | |
43 .DE | |
44 . | |
45 .2C 4v | |
46 .PP | |
47 Notice that fold(1) did not really think twice before breaking "posts" | |
48 or "authors" across two lines. This is pretty inconvenient, to say the | |
49 least. You can actually force fold(1) to break stuff at blank spaces, | |
50 using the '-s' option: | |
51 . | |
52 .1C | |
53 . | |
54 .DS | |
55 $ fold -w 54 -s 20190213_fold.txt |head -10 | |
56 fold, fmt, par: get your text in order | |
57 ============================================ | |
58 | |
59 If you happen to read plain text files (e.g., phlog | |
60 posts), you have | |
61 probably noticed that, especially on gopher, the | |
62 lines of a text file | |
63 tend to be wrapped all to a similar length. Some | |
64 authors are very strict | |
65 on the matter, and like all the lines to be | |
66 $ | |
67 .DE | |
68 . | |
69 .2C 3v | |
70 .PP | |
71 Nevertheless, the output of fold(1) is still quite off: it breaks lines | |
72 at spaces, but it does not "join" broken lines to have a more consistent | |
73 formatting. This is where fmt(1) jumps in: | |
74 . | |
75 .1C | |
76 .DS | |
77 $ fmt -w 54 20190213_fold.txt |head -10 | |
78 fold, fmt, par: get your text in order | |
79 ============================================ | |
80 | |
81 If you happen to read plain text files (e.g., phlog | |
82 posts), you have probably noticed that, especially on | |
83 gopher, the lines of a text file tend to be wrapped | |
84 all to a similar length. Some authors are very strict | |
85 on the matter, and like all the lines to be | |
86 "justified" (i.e., all adjusted to have exactly the | |
87 same length, by inserting a few spaces to get the | |
88 $ | |
89 .DE | |
90 . | |
91 .2C 5v | |
92 .PP | |
93 Now we are talking: fmt(1) seems to be able to to "the right thing" | |
94 without much effort, and it has a few other interesting options as well. | |
95 Just have a look at the manpage. Simple and clear. | |
96 . | |
97 .PP | |
98 Last but not least, par(1) can do whatever fmt(1) and fold(1) can do, | |
99 plus much, much more. For instance: | |
100 . | |
101 .1C | |
102 .DS | |
103 $ par 54 < 20190213_fold.txt | head -10 | |
104 fold, fmt, par: get your text in order | |
105 ============================================ | |
106 | |
107 If you happen to read plain text files (e.g., phlog | |
108 posts), you have probably noticed that, especially on | |
109 gopher, the lines of a text file tend to be wrapped | |
110 all to a similar length. Some authors are very | |
111 strict on the matter, and like all the lines to be | |
112 "justified" (i.e., all adjusted to have exactly the | |
113 same length, by inserting a few spaces to get the | |
114 $ | |
115 .DE | |
116 . | |
117 .1C | |
118 .PP | |
119 will give more or less the same output as fmt(1). But: | |
120 . | |
121 .1C | |
122 .DS | |
123 $ par 54j < 20190213_fold.txt | head -10 | |
124 fold, fmt, par: get your text in order | |
125 ============================================ | |
126 | |
127 If you happen to read plain text files (e.g., phlog | |
128 posts), you have probably noticed that, especially on | |
129 gopher, the lines of a text file tend to be wrapped | |
130 all to a similar length. Some authors are very | |
131 strict on the matter, and like all the lines to be | |
132 "justified" (i.e., all adjusted to have exactly the | |
133 same length, by inserting a few spaces to get the | |
134 $ | |
135 .DE | |
136 . | |
137 .1C | |
138 .PP | |
139 will additionally "justify" your lines to the prescribed width, while: | |
140 something like: | |
141 . | |
142 .1C | |
143 .DS | |
144 $ head file.h | |
145 * | |
146 * include/linux/memory.h - generic memory definition | |
147 * | |
148 * This is mainly for topological representation. We define the | |
149 * basic "struct memory_block" here, which can be embedded in per-arch | |
150 * definitions or NUMA information. | |
151 * | |
152 * Basic handling of the devices is done in drivers/base/memory.c | |
153 * and system devices are handled in drivers/base/sys.c. | |
154 * | |
155 $ | |
156 .DE | |
157 . | |
158 .1C | |
159 .PP | |
160 can be easily transformed into: | |
161 . | |
162 .1C | |
163 .DS | |
164 $ par 40j < file.h | |
165 * | |
166 * include/linux/memory.h - generic | |
167 *memory definition | |
168 * | |
169 * This is mainly for topological | |
170 * representation. We define the basic | |
171 * "struct memory_block" here, which can | |
172 * be embedded in per-arch definitions | |
173 * or NUMA information. | |
174 * | |
175 * Basic handling of the devices is | |
176 * done in drivers/base/memory.c and | |
177 * system devices are handled in | |
178 * drivers/base/sys.c. | |
179 * | |
180 * Memory block are exported via | |
181 * sysfs in the class/memory/devices/ | |
182 * directory. | |
183 * | |
184 * | |
185 $ | |
186 .DE | |
187 . | |
188 .2C 12v | |
189 .PP | |
190 Pretty neat, right? | |
191 . | |
192 .PP | |
193 To be honest, par is not the typical example of a unix tool that | |
194 "does exactly one thing", but it certainly "does it very well" all the | |
195 things it does. The author of par(1) felt the need to apologise in the | |
196 manpage about the style of his code and documentation, but I still think | |
197 par(1) is an awesome tool nevertheless. | |
198 . | |
199 .PP | |
200 .IP "fold(1)" | |
201 appeared in BSD1 (1978-1979) | |
202 . | |
203 .IP "fmt(1)" | |
204 appeared in BSD1 (1978-1979) | |
205 . | |
206 .IP "par(1)" | |
207 was developed by Adam Costello in 1993, as a replacement for fmt(1). |