Commit Graph

5 Commits

Author SHA1 Message Date
Craig Small
8fcfb01a81 misc: Update the copyrights of files
The copyrights of the source files were all out of date and were not
the same format. This has been corrected. The source of the authors
was examining the git log for each file.

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2023-02-07 21:09:48 +11:00
Justin Gottula
8a65a304e0 watch: Fix buggy line-deletion behaviour with --no-linewrap
This change is largely based upon Justin's patch, I just moved the
reset_ansi() parts out otherwise you get strange colour reset
behaviours.

Original patch message:
I used the --no-linewrap (-w) option for the first time today, watching
some wide output that didn't quite fit in my tmux pane. Quickly I
noticed a problem: while --no-linewrap did indeed eliminate the
spillover of lines too long for the terminal "window" width, it *also*
resulted in a bunch of lines from the program output being hidden
entirely.

After some fiddling around, the exact problematic behavior appears to be
as follows:
 1. Lines which would have wrapped (more than $COLUMNS chars long) are
    handled correctly.
 2. Lines which would *not* have wrapped (shorter than $COLUMNS) are
    printed; but then the next line is *not* printed! For long sequences
    of non-wrap-length lines, you get an every-other-line-is-visible
    sort of effect.

The logic underlying the problem seems to be this: in the run_command
loop, if the x loop goes all the way to completion (meaning we've
reached the right-side edge of the window area), there's a small block
of code for --no-linewrap whose main purpose is to call find_eol, which
eats input until it hits a newline (or EOF). Clearly this is intended to
be done for lines that are too long, so that the excess characters are
discarded and the input pointer is ready to go for the subsequent line.

However, this code isn't in any way conditional on the value of eolseen!
Short/wouldn't-wrap lines will have encountered a newline character
before exhausting the entire x loop, and therefore eolseen will be true.
Long/would-wrap lines will not have encountered a newline when the x
loop is exhausted, and so eolseen will be false.

Nevertheless, find_eol is called in *both* cases. For long lines, it
does what it's meant to do. For short lines, *the newline has already
been encountered and dealt with*, and so the actual effect of find_eol
is to eat the entirety of the next line, all the way through to its
newline, such that it isn't printed at all.

References:
 procps-ng/procps!157

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2023-01-18 16:46:52 +11:00
Craig Small
b2bfd76b06 watch: add -r to not rexec on terminal resize
If you have the watched program doing some other thing every time its
run and you resize the window, you might get unexpected results. The
-r option lets you run only when the interval has expired.

References:
 procps-ng/procps!125
 procps-ng/procps#190
2023-01-17 20:45:48 +11:00
Craig Small
5f4074a250 watch: Pass through bell
Based upon merge request 104, closes #174

References:
 procps-ng/procps!104
 procps-ng/procps#174
2023-01-17 16:59:00 +11:00
Craig Small
dd60d6d6e8 misc: Move all binaries to src
*.c -> src/
ps/* src/ps/
top/* src/top/

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-29 18:29:28 +10:00