Re: A question about the INTR char

[John Hein]

Thomas Dickey wrote at 18:38 -0500 on Jan 23, 2025:
 > On Tue, Jan 21, 2025 at 08:25:03PM -0500, Dennis Clarke wrote:
 > > Here is where I need to ask why a terminal would display the chars "^C"
 > > when a user hits the INTR key sequence as described in the stty settings
 > > at the time? Here is an example from an old Solaris server :
 > > 
  .
  .
 > > hubble $ ls -la /var/^C
 > > hubble $
 > > 
 > > There you see that I began to type the command "ls -la /var/" and then hit
 > > the CTRL - c sequence. Here I am careful to say lowercase "c" but I can 
 > > tell
 > > you that holding the SHIFT key and then CTRL - C uppercase works the same.
 > > Above we see that "intr = ^c" and so this all makes perfect sense.
 >  
 > > On just about any recent FreeBSD machine I can not see the CTRL-c chars at
 > > all. They simply do not appear :
  .
  .
 > I recall seeing some recent (month or two ago) comment on this,
 > with someone asking if it was an intentional change (and -- from memory)
 > that it was not intentional.
  .
  .
 > > So I have to wonder if this is a shell problem with /bin/sh on all
 > > recent FreeBSD versions or simply a nifty terminal config?
  .
  .
 > > On 6/23/24 05:25, Thomas Dickey wrote:
 > It seems like a bug to me :-)
 >  
 > > Well at least the baud rate changed but the INTR char sequence is 
 > > invisible.
 > > Is there a way to manage this with stty/terminal config?
 > 
 > probably not

I have noticed this occasionally on FreeBSD as well (although until
now after seeing your description I didn't know that I saw it on
FreeBSD and not Fedora).

So I poked around a little.  It turns out I have a couple test cases
that reproduce the symptom.

In ALL of the "invisible ^C" cases, instead of a caret (^) and a C
and newline, I see an "erase line" escape sequence (ESC + [ + K)
and newline.

Common to the reproduction cases:
 TERM=xterm
 If TERM=dumb, I cannot reproduce the invisible ^C in any attempt

 Environment variable settings are no different in any of the test cases.

 On FreeBSD, stty -a -g:
gfmt1:cflag=4b00:iflag=2b02:lflag=200005cf:oflag=3:discard=f:dsusp=19:eof=4:eol=ff:eol2=ff:erase=7f:erase2=8:intr=3:kill=15:lnext=16:min=1:quit=1c:reprint=12:start=11:status=14:stop=13:susp=1a:time=0:werase=17:ispeed=38400:ospeed=38400
 and stty -a:
speed 38400 baud; 56 rows; 109 columns;
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
        brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
        -dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
        eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
        lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
        status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;

 On Fedora, stty -g:
6d00:5:bf:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
 and stty -a:
speed 38400 baud; rows 56; columns 109; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = 
<undef>; swtch = <undef>;
start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard 
= ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff 
-iuclc ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt 
echoctl echoke -flusho -extproc

 For the FreeBSD cases, the same symptoms occur on FreeBSD 4, and
 6-14, except for case (7) (12/i386 - no visible ^C after entering
 a 'sleep 3' command and hitting ctrl-c). I think there is an
 environment difference for the latter, but I haven't been able to
 identify that yet.


Given the above here are a couple ways I tried to reproduce the invisible ^C ...

In all attempts, the following actions were performed:
Places where Ctrl + c was hit:
 - Hit Ctrl + c at the end of the 'id' line (never hit Enter)
 - Hit Ctrl + c after 'sleep 3' + Enter, before 3 seconds is up

(1) Fedora 35 + /bin/tcsh

 > id
 > sleep 3
 ^C
 >

(2) Fedora 35 + /bin/sh

 > id^C
 > sleep 3
 ^C
 >

(3) FreeBSD + /bin/sh

 > id
 > sleep 3
 ^C
 >

(4) FreeBSD + /bin/tcsh

 > id
 > sleep 3
 ^C
 >

(5) FreeBSD + /usr/bin/script + /bin/tcsh

 > id
 > sleep 3
 ^C
 >

(6) FreeBSD + /usr/bin/script + /bin/sh

 > id
 > sleep 3
 ^C
 >

(7) FreeBSD 12/i386 + /usr/bin/script + /bin/tcsh

 > id
 > sleep 3
 >

(8) FreeBSD 12/amd64 + /usr/bin/script + /bin/tcsh

 > id
 > sleep 3
 ^C
 >

I don't know what causes the shell / terminal to spit out either the
^C string or the "erase line" escape sequence (yet). But maybe this
information will help provide some strings to pull on or some feedback
from someone.