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

Closed
opened 2024-06-05 20:59:23 -06:00 by silt · 3 comments
Owner

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
emma added reference docs 2024-06-05 21:06:11 -06:00
Owner

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

I am on the side of rectifying it in the docs: skipping and seeking should start reading and writing on the byte specified.
emma added the
enhancement
question
labels 2024-06-06 01:01:18 -06:00
emma changed reference from docs to dj 2024-06-29 17:28:03 -06:00
Owner

This seems to have been fixed. #125 adds further clarification. Please reopen if you still have issue.

This seems to have been fixed. #125 adds further clarification. Please reopen if you still have issue.
Owner

#134 further clarifies this.

#134 further clarifies this.
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: bonsai/harakit#113
No description provided.