A record is what was written - #15
Merged
Merged
Conversation
The record reader trimmed spaces and tabs off both ends of every line before handing it to a verb. For a NIP-19 code or a JSON object that is harmless. For `deed encrypt` the record IS the message. `printf ' hello ' | deed encrypt` encrypted `hello`. The spaces were gone, nothing said so, and the payload is sealed, so there is no reading it back to notice. Somebody sending an indented line or significant trailing whitespace got something other than what they typed, encrypted in their name. So `Input` hands back the record as written, minus the line terminator, and the verbs whose records are a code, an event or a draft trim for themselves. A `\r` from CRLF still comes off, because that is how the line ended rather than part of what was in it. A truly empty line still separates records; a line of spaces is now a record, because for `encrypt` that is a message somebody chose to send. Two smaller ones in the same family, both about refusing to carry what the reader gave. `deed encrypt` could not send a message beginning with a hyphen: it came back as an unknown option, which is a refusal on account of a first character. `--` ends the options now, the way it does everywhere else. `deed key public` on 64 hex characters outside the curve's range printed `deed: InvalidSecretKey`, a Zig error name that escaped to the top-level handler. It now says what is wrong with what was pasted, like every other failure in that verb. Checked by restoring the trim: two of the new tests fail, one on the message and one on the line of spaces. Closes #14.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #14.
The record reader trimmed spaces and tabs off both ends of every line. For a code or a JSON object that is harmless. For
deed encryptthe record is the message.Nothing said so, and the payload is sealed, so there is no reading it back to notice.
Inputnow hands back the record as written, minus the line terminator, and the verbs whose records are a code, an event or a draft trim for themselves.\rfrom CRLF still comes off: that is how the line ended, not part of what was in it. A truly empty line still separates; a line of spaces is now a record, because forencryptthat is a message somebody chose to send.Two smaller ones, same family
Both are about refusing to carry what the reader gave.
deed encryptcould not send a message starting with a hyphen, which came back as an unknown option.--ends the options now.deed key publicon 64 hex characters outside the curve range printeddeed: InvalidSecretKey, a Zig error name that escaped to the top-level handler. It says what is wrong with the input now.Checked
49 to 53 tests. Restoring the trim fails two of the new ones, on the message and on the line of spaces.
printf " hello "through encrypthellohelloencrypt -- "-dash first"key publicwith an unusable keydeed: InvalidSecretKey