Commit Graph

9 Commits

Author SHA1 Message Date
FRIGN
98e7e75ec6 Fix last offset output using skip in od(1)
Yeah, if the skipping is longer than the file itself, we need
to take the skip value, not the address.
Also, only print the last newline when we've actually printed
at least 1 address.
2015-09-30 19:44:11 +01:00
FRIGN
8163451249 Check parseoffset return value in od(1)
Yeah, kinda embarassing. Forgot about that.
2015-09-30 19:44:10 +01: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
FRIGN
f8f2a56852 Add -j and -N to od(1) and update README
With parseoffset(), it's rather trivial to implement POSIX' rather
obscure commandments.
The -j and -N-flags should be ready to go!
2015-09-30 19:44:10 +01:00
FRIGN
7132473947 Some small changes for od(1)
1) Move usage() down above main().
2) Consistently use printaddress() across the code.
3) Use off_t instead of size_t for file offsets.
2015-09-30 19:44:10 +01:00
FRIGN
365f392d3c Properly handle namedict in od(1)
I added the [127]-index but forgot that this increases the length,
breaking a later check.
2015-09-30 19:44:10 +01:00
FRIGN
0d6d1dc02f Check explicit length in od(1)
If you pass an empty string, the null-char will always match
with strchr()!
2015-09-30 19:44:10 +01:00
FRIGN
d49bce7fc8 Refactor parts of od(1)
It was possible to make some sections of the code shorter.
Also fix a bug where the last printed address was always in hex
rather than depending on the radix chosen.
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