suckless
/
sbase
mirror of git://git.suckless.org/sbase
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
sbase/od.1

63 lines
1.3 KiB
Groff
Raw Normal View History

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-25 22:26:49 +00:00
.Dd 2015-10-25
Created od, with improvements suggested by FRIGN
2015-09-29 01:02:17 +00:00
.Dt OD 1
.Os sbase
.Sh NAME
.Nm od
.Nd octal dump
.Sh SYNOPSIS
.Nm
Update od(1)-documentation
2015-10-09 01:09:26 +00:00
.Op Fl A Ar addrformat
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-25 22:26:49 +00:00
.Op Fl E | e
Update od(1)-documentation
2015-10-09 01:09:26 +00:00
.Op Fl t Ar outputformat...
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 10:54:24 +00:00
.Op Fl v
Update od(1)-documentation
2015-10-09 01:09:26 +00:00
.Op Ar file ...
Created od, with improvements suggested by FRIGN
2015-09-29 01:02:17 +00:00
.Sh DESCRIPTION
.Nm
writes an octal dump of each
.Ar file
to stdout. If no
.Ar file
Update od(1)-documentation
2015-10-09 01:09:26 +00:00
is given
Created od, with improvements suggested by FRIGN
2015-09-29 01:02:17 +00:00
.Nm
reads from stdin.
.Sh OPTIONS
.Bl -tag -width Ds
Update od(1)-documentation
2015-10-09 01:09:26 +00:00
.It Fl A Ar addressformat
.Ar addressformat
is one of d|o|x|n and sets the address to be
either in \fId\fRecimal, \fIo\fRctal, he\fIx\fRadecimal or \fIn\fRot
printed at all. The default is octal.
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-25 22:26:49 +00:00
.It Fl E | e
Force Little Endian
.Fl ( e )
or Big Endian
.Fl ( E )
system-independently.
Update od(1)-documentation
2015-10-09 01:09:26 +00:00
.It Fl t Ar outputformat
.Ar outputformat
is a list of a|c|d|o|u|x followed by a digit or C|S|I|L and sets
the content to be in n\fIa\fRmed character, \fIc\fRharacter, signed
Created od, with improvements suggested by FRIGN
2015-09-29 01:02:17 +00:00
\fId\fRecimal, \fIo\fRctal, \fIu\fRnsigned decimal, or
Update od(1)-documentation
2015-10-09 01:09:26 +00:00
he\fIx\fRadecimal format, processing the given amount of bytes or the length
of \fIC\fRhar, \fIS\fRhort, \fII\fRnteger or \fIL\fRong.
The default is octal with 4 bytes.
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 10:54:24 +00:00
.It Fl v
Always set. Write all input data, including duplicate lines.
Created od, with improvements suggested by FRIGN
2015-09-29 01:02:17 +00:00
.El
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-08 23:46:56 +00:00
.Sh STANDARDS
The
.Nm
utility is compliant with the
.St -p1003.1-2013
specification.
.Pp
The
.Op Fl v
flag is enabled by default and the 'd' parameter for the
.Op Fl t
flag is interpreted as 'u'.
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-25 22:26:49 +00:00
.Pp
The
.Op Ee
flags are an extension to that specification.