0

bind command can bind a key sequence to a Readline function or a macro.The key sequence of f5 is \e[15~,i bind f5 with pkill.

ffplay  movie.mp4
bind -x '"\e[15~":"pkill ffplay"'

Now press f5, the movie stop playing.

The expression $(command) stands for command substitution; it means run command and put its output here.

echo "it is time to dig '\$(tput kf5)' on $(date)."
it is time to dig '$(tput kf5)' on Sat 07 May 2022 09:50:07 PM HKT.

Show result of $(tput kf5):

debian@debian:~$  echo "$(tput kf5)"

debian@debian:~$  echo '$(tput kf5)'
$(tput kf5)

No \e[15~ output here.Why bind -x '"$(tput kf5)":"pkill ffplay"' take as same effect as bind -x '"\e[15~":"pkill ffplay"'?

showkey
  • 482
  • 42
  • 140
  • 295
  • You have a typo, should be `tput`. – Philippe May 07 '22 at 13:58
  • 1
    Removed the "bind" tag because the bind keyword is predominantly used with non-bash meanings, added libreadline (as bind tells bash to configure the readline library). – Charles Duffy May 07 '22 at 13:59
  • As for the question, though, `fput` isn't a command that exists. Where did you see documentation that says it was what you should use? As Phillipe says, the standard command for looking up terminal control sequences is `tput`. – Charles Duffy May 07 '22 at 14:01
  • (and the edit that says you get `tput: command not found` on Debian is frankly hard to believe, unless you've done something like corrupting your PATH and can't successfully run _any_ external commands). – Charles Duffy May 07 '22 at 14:02
  • ...according to https://packages.debian.org/bullseye/ncurses-bin, tput is part of the Debian packages `ncurses-bin`. That should be installed by default out-of-the-box, but if you're running a cut-down / minimal instance of the distro, make sure you have it installed. – Charles Duffy May 07 '22 at 14:04
  • I fix the typo,issue related to `https://stackoverflow.com/questions/72114694/how-can-kill-all-the-processes-triggered-by-hotkey-with-some-smart-way`. – showkey May 07 '22 at 14:05
  • 1
    As for not seeing `\e[15~` when you look at the output of `tput` with `echo`, you're using the wrong tool. `tput` doesn't need to emit a `\e` sequence when it can spit out a literal escape character; pipe its output to `cat -A` or `od -c` or `hexdump` or another tool that can show you nonprintable characters and you'll see a literal escape, not a `\e` sequence meant to be turned into a literal escape later. – Charles Duffy May 07 '22 at 14:05
  • ...also, the behavior of `echo` is very poorly defined, so even if it _was_ a literal escape sequence, echo wouldn't necessarily print it (even if the shell is known to be bash, echo has several modes). See https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html, the POSIX specification for `echo`, which itself recommends using `printf` instead whenever the input contains backslashes (among other circumstances). For a more extensive discussion, see see [Why is printf better than echo?](https://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo) on [unix.se]. – Charles Duffy May 07 '22 at 14:10
  • (if you're curious as to what I mean when I say "echo has several modes" even in bash, look into how the `xpg_echo` runtime flag -- which can also be set at compile time -- modifies `echo`'s behavior, and how it interacts with `set -o posix`; there are a lot of different, mutually-incompatible behaviors one can get out of such a simple-looking command). – Charles Duffy May 07 '22 at 14:13

1 Answers1

0
echo "$(tput kf5)" | cat -A
^[[15~$
showkey
  • 482
  • 42
  • 140
  • 295