Oldest OS with Ctrl-T ?

Maybe that Linux is "famously" missing SIGINFO and some tools therefore resort to SIGUSR1 ?

(edit, might indeed be worth adding in a neutral, aka "non-bashing" way: A signal to output status information was deemed useful by some tools/applications, so they sometimes do that on getting SIGUSR1 on operating systems not implementing SIGINFO ?)
 
On VMS, if you press Ctrl-T, you will always get some useful information. If a program doesn't implement a specific handler for it (and I don't even remember how to do that, but I've done it before, about 30 years ago), the rest of the OS (probably DCL) will catch it and display something.

On the BSDs, it seems to be usually disabled. That makes sense: The default action in signal for SIGINFO is to ignore. But there is a nokerninfo flag in the termios structure (accessible via the stty command from the shell), and in theory the kernel should display information in response to Ctrl-T, even when you are at the shell prompts (after all, the shell is just a program that the user runs). Why doesn't it? I tried toggling nokerninfo on and off, and it seems to make no difference.
 
ralphbsz said:
On VMS, if you press Ctrl-T, you will always get some useful information. If a program doesn't implement a specific handler for it (and I don't even remember how to do that, but I've done it before, about 30 years ago), the rest of the OS (probably DCL) will catch it and display something.

On the BSDs, it seems to be usually disabled. That makes sense: The default action in signal for SIGINFO is to ignore. But there is a nokerninfo flag in the termios structure (accessible via the stty command from the shell), and in theory the kernel should display information in response to Ctrl-T, even when you are at the shell prompts (after all, the shell is just a program that the user runs). Why doesn't it? I tried toggling nokerninfo on and off, and it seems to make no difference.
Click to expand...

At a shell prompt, the shell will set your terminal modes. When the shell launches a program it changes the terminal modes right before it does that (before "exec").

In the following example tcsh prompt is using /dev/pts/0 while I use stty from tcsh running on /dev/pts/1

Then I run "sleep 60" on /dev/pts/0 and capture the stty output on /dev/pts/1

Running diff on the captured output from stty is pretty crummy as it doesn't hand changes across lines well, but it shows there are differences in how the terminal is configured just by launching a program from the shell.

Code: 
root@freebsd:~ # w
12:03AM  up 30 secs, 2 users, load averages: 2.58, 0.80, 0.30
USER       TTY      FROM                     LOGIN@  IDLE WHAT
ambie       pts/0    lakshmi.trickster.gods  12:03AM     - -tcsh (tcsh)
ambie       pts/1    lakshmi.trickster.gods  12:03AM     - w


root@freebsd:~ # stty all < /dev/pts/0 > 01-tcsh-prompt-stty
root@freebsd:~ # stty all < /dev/pts/0 > 02-sleep-stty
root@freebsd:~ # diff -u 01-tcsh-prompt-stty 02-sleep-stty
--- 01-tcsh-prompt-stty    2023-09-06 00:04:40.433799000 +0000
+++ 02-sleep-stty    2023-09-06 00:04:52.513636000 +0000
@@ -1,15 +1,15 @@
 speed 38400 baud; 24 rows; 80 columns;
-lflags: -icanon isig -iexten -echo echoe -echok echoke -echonl echoctl
+lflags: icanon isig iexten echo echoe echok echoke -echonl echoctl
     -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
     -extproc
-iflags: -istrip icrnl inlcr -igncr ixon -ixoff -ixany -imaxbel -ignbrk
+iflags: -istrip icrnl -inlcr -igncr ixon -ixoff -ixany -imaxbel -ignbrk
     brkint -inpck -ignpar -parmrk
 oflags: opost onlcr -ocrnl tab0 -onocr -onlret
 cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
     -dtrflow -mdmbuf rtsdtr
 discard dsusp   eof     eol     eol2    erase   erase2  intr    kill   
-^O      <undef> <undef> <undef> <undef> ^?      ^H      ^C      ^U     
+^O      ^Y      ^D      <undef> <undef> ^?      ^H      ^C      ^U     
 lnext   min     quit    reprint start   status  stop    susp    time   
-<undef> 1       ^\      <undef> ^Q      <undef> ^S      <undef> 0       
+^V      1       ^\      ^R      ^Q      ^T      ^S      ^Z      0       
 werase 
-<undef>
+^W     
root@freebsd:~ #
 
This is interesting info... A few suggestions I have:
  • If you want to emphasize the idea that Ctrl-T is an old idea, it might be good to include the year info for every OS mentioned... Right now, the article only mentions the year for the DEC RSTS/E OS, and not others.
  • The section about Application-level implementations only has 1 example... As a reader, I kind of expected more than 1. Also - application-level status report is a pretty unwieldy topic that does happen to be of interest when you have long-running jobs (like compiling the kernel, lang/gcc or a graphics/blender render, or a download). If a job is taking forever, I'd want to know if it's half done, more than half, how much time is left, and maybe some detail on where things stand (register values, time elapsed, what command was even issued, and the like - that kind of stuff is normally reported by top and ps...
  • Maybe add a short explanation of how OS-level implementation is different from application-level implementation? Like, on the OS level, one cares more about process state reporting, while on application level, a user cares more about how much progress a compiler made. Wikipedia's audience is not just experts who can infer information that's not included, or be bothered to go looking for further info to connect the dots... It may be a lot of work for one author, but putting in that effort is what helps Wikipedia's efforts to be a credible source of info.
  • Was this Ctrl-T idea ever a POSIX or ISO standard?
  • If the article is meant to be a technical history lesson, it might be good to have a few sentences about how status reporting became popular and complex.
 
You must log in or register to reply here.
Back
Top