1. 30
  1.  

  2. 5

    With a xterm and ksh on OpenBSD I just see ^T and nothings happens. When I manually send a SIGINFO it works as expected. What am I doing wrong?

    Edit, solved: I needed to run “stty status ^T” on ksh invocation.

    1. 4

      I never understood why Linux doesn’t just add that.

      1. 5

        The last thing we want to do is adding more functionalities to the tty layer and adding more signals.

        1. 1

          Actually, it’s a standard feature that is missing as far some (old) people are concerned.

          Standard since at least the early 1970s and implemented in TOPS-10, TENEX, TOPS-20, RSTS, and VMS, but not RSX, as I recall. I believe it was a feature of WAITS as well.

          I don’t recall it in V7M or 32V, and it was certainly not in System III or System V.

          Not sure when it was implemented in BSD, but it is present 2.11BSD.

          1. 1

            Also, in the earlier systems, Control-T was actually implemented in the monitor, so it would elicit a response even if pretty much everything else was swamped or broken.

            The downside is that sending a flood of Control-T’s would slow down everything else and could be used for annoyance.

        2. 2

          The USR1 signal is supported on Linux for making dd report the progress. Implementing something similar for cp and other commands, and then make ctrl-t send USR1 can’t be too hard to implement. Surely, it is not stopped by the Linux kernel itself?

          1. 8

            SIGUSR1 has an nasty disadvantage relative to SIGINFO: by default it kills the process receiving it if no handler is installed. 🙁 The behavior you really want is what SIGINFO has, which is defaulting to a no-op if no handler is installed.

            • I don’t want to risk killing a long-running complicated pipeline that I was monitoring by accidentally sending SIGUSR1 to some process that doesn’t have a handler for it
            • there’s always a brief period between process start and the call to signal() or sigaction() during which SIGUSR1 will be lethal
            1. 1

              That’s interesting. The hacky solution would be to have a whitelist of processes that could receive SIGUSR1 when ctrl-t was pressed, and just ignore the possibility of someone pressing ctrl-t at the very start of a process.

              A whitelist shouldn’t be too hard to maintain. The only tool I know of that handles SIGUSR1 is dd.

            2. 5

              On BSD it’s part of the TTY layer, where ^T is the default value of the STATUS special character. The line printed is actually generated by the kernel itself, before sending SIGINFO to the foreground process group. SIGINFO defaults to ignored, but an explicit handler can be installed to print some extra info.

              I’m not sure how equivalent functionality could be done in userspace.

              1. 1

                It would be a bit hacky, but the terminal emulator could send USR1 to the last started child process of the terminal, when ctrl-t is pressed. The BSD way sounds like the proper way to do it, though.

                1. 4

                  I have a small script and a tmux binding for linux to do this:

                  #!/bin/sh
                  # tmux-signal pid [signal] - send signal to running processes in pids session
                  # bind ^T run-shell -b "tmux-signal #{pane_pid} USR1"
                  
                  [ "$#" -lt 1 ] && return 1
                  sid=$(cut -d' ' -f6 "/proc/$1/stat")
                  sig=$2
                  : ${sig:=USR1}
                  ps -ho state,pid --sid "$sid" | \
                  while read state pid; do
                          case "$state" in
                          R) kill -s"$sig" "$pid" ;;
                          esac
                  done
                  
                  1. 4

                    Perfect, now we only need to make more programs support USR1 and lobby for this to become the default for all Linux terminal emulators and multiplexers. :)

            3. 2

              I can’t believe there was a way to get the progress of a copy tucked away all this time, I have wanted that many times.

              1. 3

                If you don’t mind setting up a pipeline, pv could work if you do it before running the command.