Commit Graph

10 Commits

Author SHA1 Message Date
Michael Forney 22921a859f Fix various lint warnings in manuals
Fix "new sentence, new line" warnings throughout so that formatters
can produce correct spacing between sentences.

join.1
  Remove unnecessary Ns macros. These are not necessary for delimeters,
  which get special treatment.

xinstall.1
  Fix date in manual. The contents were last modified on 2016-12-03,
  so use that instead of the invalid date.

grep.1
  Fix escape sequence for `\<` and `\>`.

ed.1
  Remove spurious `\\n` escape for the null-command.
2020-03-01 15:32:11 -08:00
Michael Forney 5ae2793da6 od: Add some missing type flags 2016-07-09 10:17:16 +01:00
Greg Reagle c0a63db7f2 od: document skip (-j) option 2015-11-06 10:18:56 +00:00
Greg Reagle 9b7e560781 od: more accurate statement of compliance with POSIX 2015-10-31 10:41:33 +00:00
FRIGN d03baf1697 Add -e and -E flags to od(1) and properly handle endianness
The -e and -E flags allow the user to override the host endianness
and force od(1) to handle input according to a little (-e) or big (-E)
endian environment.
The previous handling was broken as bitshifts alone are already
endian-independent.
2015-10-26 11:55:41 +00:00
FRIGN c619e168c9 Update od(1)-documentation 2015-10-26 11:55:41 +00:00
FRIGN 092c95b66c Rewrite od(1)
Looking at the old code, it became clear that the desired
functionality with the t-flag could not be added unless the
underlying data-structures were reworked.
Thus the only way to be successful was to rewrite the whole thing.

od(1) allows giving arbitrarily many type-specs per call, both via
-t x1o2... and -t x1 -t o2 and intermixed.
This fortunately is easy to parse.
Now, to be flexible, it should not only support types of integral
length. Erroring out like this is inacceptable:

$ echo -n "shrek"| od -t u3
od: invalid type string ‘u3’;
this system doesn't provide a 3-byte integral type

Thus, this new od(1) just collects the bytes until shortly before
printing, when the numbers are written into a long long with the
proper offset.
The bytes per line are just the lcm of all given type-lengths and >= 16.
They are equal to 16 for all types that are possible to print using
the old od(1)'s.

Endianness is of course also supported, needs some testing though,
especially on Big Endian systems.
2015-10-26 11:55:41 +00:00
FRIGN e51a2e6d2f Use ISO-date-format in manpages
The one specified by mdoc is hard to read for non-native
speakers from countries which read the date day-first (like
Germany, Greece, North-Korea, Swamp,...).
This is also consistent with how we generally specify dates
at suckless.org.
2015-10-08 17:15:08 +02:00
FRIGN fc886aa144 Implement od(1) v-flag
If this flag is not given, od(1) automatically replaces duplicate
adjacent lines with an '*' for each reoccurence.
If this flag is set, thus, no such filtering occurs.

In this case this would mean having to somehow keep the last printed
line in some backbuffer, building the next line and then doing the
necessary comparisons. This basically means that we duplicate the
functionality provided with uniq(1).

So instead of

$ od -t a > dump

you'd rather do

$ od -t a | uniq -f 1 -c > dump

Skipping the first field is necessary, as the addresses obviously differ.

Now, I was thinking hard why this flag even exists. If POSIX mandated
to add the address before the asterisk, so we know the offset of duplicate
occurrences, this would make sense. However, this is not the case.

Using uniq(1) also gives nicer output:
~ $ echo "111111111111111111111111111111111111111111111111" | od -t a -v | uniq -f 1 -c
      3 0000000   1   1   1   1   1   1   1   1   1   1   1   1   1   1   1   1
      1 0000060  nl
      1 0000061

in comparison to

$ echo "111111111111111111111111111111111111111111111111" | od -t a
0000000   1   1   1   1   1   1   1   1   1   1   1   1   1   1   1   1
*
0000060  nl
0000061

Before working on od(1), I didn't even know it would filter out
duplicate adjacent lines like that. This is also a matter of
predictability.

Concluding, the v-flag is implicitly set and users urged to just
use the existing tools provided by the system.
I don't think we would break scripts either. Firstly, it's rather
unlikely to have duplicate lines exactly matching the line-length of
od(1). Secondly, even if a script did that specifically, in the worst
case there would be a counting error or something.

Given od(1) is mostly used interactively, we can safely assume this
feature is for the benefit of the users.

Ditch this legacy POSIX crap!
 Please enter the commit message for your changes. Lines starting
2015-09-30 19:44:10 +01:00
Greg Reagle fd0d1e4567 Created od, with improvements suggested by FRIGN 2015-09-30 19:44:10 +01:00