Re: a really big question : why not "^C" for a CTRL-C with default /bin/sh ?
- In reply to: Konstantin Belousov : "Re: a really big question : why not "^C" for a CTRL-C with default /bin/sh ?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 02 Nov 2025 09:35:13 UTC
It depends. It depends on what *BSD you are using with which shell. it is different for different Gnu/Linux based distributions. Pauschally telling it prints "CTRL-C" als "^C" in any cases if wrong. As told: it depends on what *NIX you are operating which shell. Sometimes even bash prints typed CTRL-C as ^C, sometimes it just does only for keys not bound to anything. Looking at involved programs and libraries configurations, they are different on these systems. And it is quite difficult to transfer one configuration from one system to another, without breaking something you'd never imagined. I'd say it is mostly configuration if CTRL-C is printed as ^C or not. On Sun, Nov 2, 2025 at 6:39 AM Konstantin Belousov <kostikbel@gmail.com> wrote: > On Sat, Nov 01, 2025 at 10:44:54PM -0600, Warner Losh wrote: > > On Sat, Nov 1, 2025 at 7:49 PM Dennis Clarke <dclarke@blastwave.org> > wrote: > > > > > On 11/1/25 21:22, cyric@mm.st wrote: > > > > Dennis Clarke wrote: > > > >> On 11/1/25 20:30, Michael Gmelin wrote: > > > >>> > > > >>> > > > >>>> On 2. Nov 2025, at 00:34, Dennis Clarke <dclarke@blastwave.org> > > > wrote: > > > >>>> > > > >>>> > > > >>>> This is about as annoying as a small sharp stone stuck in a shoe : > > > >>>> > > > >> ... > > > >>> Wasn‘t this always the default behavior in /bin/sh? > > > >>> > > > >> > > > >> If it was and if it is then it is broken and always has been. > > > >> > > > >> No UNIX shell *ever* behaves this way in at least the last four > decades. > > > > > > > > zsh does, ksh93 (illumos) does. > > > > > > > > > > Those both hide the CTRL-C "^C" chars ? > > > > > > Oracle Solaris 11.4.81.193.1 Assembled April 2025 > > > n$ > > > n$ uname -a > > > SunOS neptune 5.11 11.4.81.193.1 sun4v sparc sun4v non-virtualized > > > n$ echo $SHELL > > > /usr/xpg4/bin/sh > > > n$ > > > n$ ls la la la la la ^C > > > n$ > > > n$ which ksh93 > > > /usr/bin/ksh93 > > > n$ > > > n$ ksh93 > > > dclarke@neptune:~$ > > > dclarke@neptune:~$ and then we have Dave Korn > > > dclarke@neptune:~$ well look ... no CTRL-C ^C chars ? > > > > > > dclarke@neptune:~$ > > > > > > Nice one. I did not recall the ksh93 issue. Must be something in the > > > stty options being set or unset. > > > > > > > tcsh doesn't report it at the prompt (most likely because libedit is in > > play), but does if you type cat<return> and then ^C. > > When the terminal in the canonical mode, kernel prints ^C for Ctrl-C > input, as you noted for cat. There are a lot of termios controls that > combined give that behavior, like isig etc. > > When the terminal is in raw mode, as set by shells with more than basic > line editing capabilities, kernel does not output anything on Ctrl-C, > and shells or rather libedit do not bother. > > Spawning the command, shells switch the ctty into the canonical mode, > this is why tcsh+cat behaves that way. > > BTW, it seems bash (readline) does print ^C. > > -- Thomas