peek(1) #93
Labels
No Label
bug
duplicate
enhancement
help wanted
invalid
joke
question
wontfix
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Depends on
#96 testing
bonsai/harakit
Reference: bonsai/harakit#93
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "peek"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
peek(1) is a utility that reads standard input and writes to given outputs without echoing to the terminal. It has a number of features that make safer usage convenient and both the code and the man page are very cleanly written. This tool's utility is obvious in the examples; while shell scripts shouldn't accept secrets, if they were to do so this is a thoughtfully designed utility for that task.
This is imported from my source tree with slight tweaks for this repository. @silt helped review this code when it was first written (four months ago).
mm(1) isn't suited for this task because it doesn't prevent terminal echoing. The shell built-in
read
doesn't either. The featureset of this utility wouldn't make sense for any other one, either (-1
could be| head -n 1
,-e
could be| tee /dev/stderr
,-n
could be| tr -d \\n
,-o
is a default everywhere,-p
is a pipe, and-t
doesn't make sense elsewhere).@ -0,0 +19,4 @@
.SH DESCRIPTION
Peek reads input from standard input with terminal echo disabled, which may be
Read input from the standard input with terminal echo disabled.
Should this be placed in a RATIONALE section?
@ -0,0 +45,4 @@
.B -o
.RS
Configures peek to output to standard output.
“[...] the standard output”
@ -0,0 +48,4 @@
Configures peek to output to standard output.
.RE
.B -p
What is the benefit to this over using a shell pipe?
@ -0,0 +94,4 @@
.R $ env -i PATH="$PATH" peek -1tp htpasswd -nBi _ | cut -d : -f 2
.RE
This is a POSIX sh(1) command line that lets a user blindly write into a text
Either:
or:
Could this functionality be attained using a combination of existing or hypothetical utilities and shell features? We should consider whether this utility should be necessary for its use case.
Yes, actually. After rethinking it I rewrote the utility to be as simple as possible (and have
-t
be the default as it should have been). The man page has been updated to match, including incorporating all of your comments which I found to be useful.peek(1)to WIP: peek(1)WIP: peek(1)to peek(1)@ -0,0 +27,4 @@
.SH DIAGNOSTICS
Peek prints an error message and exits with the appropriate status from
For parity with the man pages in the
docs
branch. For example, seenpc.1
.@ -0,0 +30,4 @@
Peek prints an error message and exits with the appropriate status from
sysexits.h(3) if it encounters an unrecoverable error.
Peek tries to handle the signal SIGINT (^C) to ensure the user's terminal is
If it encounters a SIGINT signal (^C), the program will attempt to handle it to ensure the user’s terminal is still usable after premature termination; if the signal can’t be handled, it prints an error message and continues. If the program is interrupted, it exits unsuccessfully and without printing an error message.
@ -0,0 +44,4 @@
.SH BUGS
This does nothing to prevent others seeing the keyboard being used to input
This being in the BUGS section implies that this can be fixed by the program. Therefore, this belongs in a CAVEATS section because it is definitionally a caveat.
@ -0,0 +69,4 @@
This is an sh(1p) command line that lets a user blindly write into a text file,
only able to see written lines. Some writers have the habit of prematurely
revising their work and use tools like this to prevent it. It uses mm(1) to
pipe the output of peek to both the standard error and the regular file
Here is the sum of the changes I recommend to the
peek.1
manpage as a git diff:Could "inputted" be "input"? Otherwise I like these changes and you may merge them into the peek branch, or I can myself when I'm at keyboard.
@ -0,0 +20,4 @@
.SH OPTIONS
.IP \fB-i\fP
Allows input to come from sources other than terminals (i.e., a pipe).
This appears to imply that there exists a multitude of other possible sources, but it's not made clear what those are or how to make use of them. Does it support reading input from… files? TCP sockets? IRC messages??
The "i.e." stands for "id est" and can be read as "in other words". Perhaps I should use the English. I mean to say that the source other than a terminal, in this case, is a pipe.
Changed to (pipes) which I think is more clear.
I’m still not convinced that this should be a tool instead of a shell feature, like some sort of
set
analogue that lets you disable echoing.It's about the fundamentals.
A program should do one thing well. peek(1) does one thing well. Mixing its functionality into another program is unnecessary, makes it generally less valuable, and makes the other program more complex.
My git client was misconfigured; I've signed a child commit to endorse the previous commits, but let me know if there's anything else I should do.
You’re good, the merge commit will be signed anyway
After some thought, I agree with this.
@ -0,0 +4,4 @@
.\" This work is licensed under CC BY-SA 4.0. To see a copy of this license,
.\" visit <http://creativecommons.org/licenses/by-sa/4.0/>.
.\"
.TH PEEK 1 2024-06-09 "Bonsai Core Utilites 0.13.9"
I can't find a way to rewrite this in Rust without vendoring a crate or writing termios C bindings.
I didn't know about stty(1p) when I wrote this utility but I think for this purpose peek(1) does a better job.
@ -0,0 +64,4 @@
#ifdef __OpenBSD__
pledge("stdio tty unveil", NULL);
unveil(NULL, NULL);
#endif
Remember to handle the possible errors here!
looks fine to me
I requested (in private messages) silt's review because a number of changes were required last-minute to make testing work (
peek -i </dev/null >/dev/null
would fail).Merged (via cherry-picking to avoid redundant commits).
Pull request closed