When measuring elapsed times, instead of executing date(1) to get the current time, use $SECONDS:

       SECONDS
              Each time this parameter is referenced, the
              number of seconds since shell invocation
              is returned.  If  a  value  is  assigned
              to  SECONDS,  the  value returned  upon
              subsequent references is the number of
              seconds since the assignment plus the
              value assigned.  If SECONDS is unset, it
              loses its special properties, even if it is
              subsequently reset.

Like so:

  throttle() {
    local -i limit
    ((limit = SECONDS + $1))
    while read line; do
      if ((limit < SECONDS)); then
        ((limit = SECONDS + $1))
        echo "$line"
      fi
    done
  }

Try it like so:

  $ yes | throttle 2

Of course, that's a bad example in that yes(1) will go as fast as you let it and it always outputs the same thing. In the case of yes(1) the better thing to do would be to sleep between reads, but yes(1) is a special case.

It's worth noting that OP's example works in any Bourne-compatible shell. I don't think `date +%s` is costly enough to warrant losing the portability.

I wouldn't be worried about the performance cost of using `date +%s` personally, I'd be concerned about what happens when the user or an automated process changes the system time.

For example, what will happen in the debounce function if the user sets the system time backwards by a week after a limit has been set?

Good point, didn't think of that.

The title said bash.

Replace "local" with "typeset" and what I wrote is compatible with KSH too -- not Bourne nor POSIX, I know, but still.

The term debouncing is also used in an analogous manner for electromechanical switches and is probably the origin of the term. These switches literally 'bounce' off the contact during the first few milliseconds after the circuit is closed, rapidly opening and closing the circuit. Debouncing attempts to filter out these rapid, unwanted changes by e.g. adding a capacitor in parallel.

>For example it exists both in React and JavaScript

There is a funny hot take in there somewhere...

Oh no.

Haha, thanks!

This seems more like a throttle rather than a debounce:

https://css-tricks.com/debouncing-throttling-explained-examp...

Good script.

I have this touchpoint problem too. Since I hate those red eraser nubs anyways, I actually disable them entirely at the xinput level. This breaks the physical right mouse button. (because Linux, ofc) but fortunately the touchpad driver replaces it.

Better overall experience without any chance of pausing as the driver bounces back.