`tput rc` stops working in a long output

[luolong]

Discord username (optional)

luolong

Describe the bug

I am playing with some tput magic on Warp and I am seeing some weird behavior. Basically, I have written a script that issues same (git) command for a set of folders (git repos), displaying output of all those commands in console.

Often though I am not really interested in the mojority "everything is up to date" messages and I would like to erase those outputs as they do not add any value to the composite output.

So, I use tput sc along with tput rc; tput ed when the most recent output is deemed "uninteresting".

It seems to be working fine, but at some point, the tput rc appears to stop working and no longer moves cursor to the most recent tput sc position.

To Reproduce

I cooked up a minimal test script (using fish shell) to demonstrate what is happening:

The script depends on curl and jq for convenience, but I am certain, something similar can be constructed in bash and without any dependencies:

#!/usr/bin/env fish
for i in (seq 30)
    set -l count 10

    set_color -o white
    echo \n(string pad -c '0' -w 2 "$i")'> curl -s' "https://www.lipsum.com/feed/json?amount=$count&what=paras&start=yes" \| jq -r '.feed.lipsum'
    set_color normal
    
    tput sc
    curl -s "https://www.lipsum.com/feed/json?amount=$count&what=lines&start=yes" | jq -r '.feed.lipsum'
    sleep 0.3
    tput rc
    sleep 0.1
    tput ed
end

I put in some small delays so that each tput action can be visually observed.

Expected behaviour

After the script completes, I expect the output to only contain bold white headers for each repetition and none of the output from lipsum.com.

Screenshots

Here's the short video of how this looks on my machine:

https://user-images.githubusercontent.com/133101/182337696-7b0367e5-6d10-4c71-9fdd-c6e4ee81eddd.mp4

As you can see, tput rc starts to break up after first line of output scrolls out of view and gets worse after that

Operating System

MacOS

OS Version

12.4 (21F79)

Shell Version

fish, version 3.5.1

Warp Version

v0.2022.07.25.09.05.stable_01

Additional context

No response

Does this block you from using Warp daily?

No

Warp Internal (ignore): linear-label:b8107fdf-ba31-488d-b103-d271c89cac3e

No response

[elviskahoro]

Will get back to you once there's progress!

[alokedesai]

@luolong This may have been fixed with our most recent release? Would you mind checking if you are still able to repro?

[luolong]

It seems that v0.2022.08.01.09.12.stable_02 still has this issue.

[alokedesai]

Thanks for clarifying @luolong. Could you post a video of what this looks like in iterm (or another terminal)? I want to make sure I fully understand what the expected behavior should be

[luolong]

For a while it seemed to me that iTerm ignored the tput sc, tput rc and/or tput ed commands. It seems I had some settings on iTerm that prevented scripts from clearing the screen.

I tried it today and it seems that both, iTerm and Terminal.app both exhibit similar problem.

With Terminal.app I also noticed that in its default configuration (smaller font and much smaller initial window size), the demo script started to fail on the first couple of iterations.

It seems that all terminals fail to properly clear the last output from curl when the output (before clearing) causes terminal to start scrolling.

[alokedesai]

@luolong Thanks for confirming! So just to confirm, this is not a bug in Warp and it repros in other terminals too? If so, I may close it :)

[luolong]

It is weird though. I would argue it is unexpected behavior at the least. It just seems to me that all terminals have a roughly similar buggy behavior.

As what should the behavior be by the specification, is somewhat hard to figure out, as my only sources for the expected behavior are man pages for tput(1) and terminfo(5).

[elviskahoro]

Will close then. @luolong Maybe we should file an issue with tput directly?