dj(1): writing/reading should take place at seeked/skipped byte #113

New Issue

2024-06-05T20:59:23-06:00

silt commented

2024-06-05 20:59:23 -06:00

From DESCRIPTION in dj(1) (docs branch):

When seeking or skipping to a byte, writing or reading starts at the byte immediately subsequent to the specified byte.

This is, in my view, undesirable. Suppose I want to use dj to programmatically write to various positions within a file, specified by a shell variable. I could construct a command such as dj -s $POS, and would expect to be able to simply specify the first index (either 0 or 1 depending on the implementation) to write to the first byte in the file. The current implementation of dj actually behaves in this manner, with the byte indices starting at 0.

$ printf '0123456789' | dj -s 0 -c 1 -b 1 2> /dev/null
0

$ printf '0123456789' | dj -s 1 -c 1 -b 1 2> /dev/null
1

While I view this as a good thing, there's a clear disagreement between the documentation and the implementation that needs to be rectified. Ideally, that rectification takes place within the docs, but this obviously warrants some discussion.

From `DESCRIPTION` in `dj(1)` (docs branch): > When seeking or skipping to a byte, writing or reading starts at the byte immediately subsequent to the specified byte. This is, in my view, undesirable. Suppose I want to use `dj` to programmatically write to various positions within a file, specified by a shell variable. I could construct a command such as `dj -s $POS`, and would expect to be able to simply specify the first index (either 0 or 1 depending on the implementation) to write to the first byte in the file. The current implementation of `dj` actually behaves in this manner, with the byte indices starting at 0. ```sh $ printf '0123456789' | dj -s 0 -c 1 -b 1 2> /dev/null 0 ``` ```sh $ printf '0123456789' | dj -s 1 -c 1 -b 1 2> /dev/null 1 ``` While I view this as a good thing, there's a clear disagreement between the documentation and the implementation that needs to be rectified. Ideally, that rectification takes place within the docs, but this obviously warrants some discussion.

emma was assigned by silt

2024-06-05 20:59:24 -06:00

trinity was assigned by silt

2024-06-05 20:59:24 -06:00

silt referenced this issue

2024-06-05 20:59:52 -06:00

docs: fixed formatting of many manpages #86

emma added reference docs

2024-06-05 21:06:11 -06:00

emma commented

2024-06-05 21:06:21 -06:00

I am on the side of rectifying it in the docs: skipping and seeking should start reading and writing on the byte specified.