Date: Sun, 2 Nov 2025 23:03:31 +0700 From: cyric@mm.st To: freebsd-current@freebsd.org Subject: Re: a really big question : why not "^C" for a CTRL-C with default /bin/sh ? Message-ID: <7b3acdda-0837-4cb6-a94c-ea79cabef6c6@mm.st> In-Reply-To: <4c330c49-1c45-46cf-9d1e-afce745e8f88@smo.de> References: <f5929936-1184-46e6-929b-72fe460719aa@blastwave.org> <864EE1FC-1533-47D4-A395-C24F25269EE0@freebsd.org> <342c6a91-a8a1-483d-861e-8e8c6d79998f@blastwave.org> <9ea41e44-7160-40eb-9d80-b8bf13a7f396@mm.st> <4c330c49-1c45-46cf-9d1e-afce745e8f88@smo.de>
index | next in thread | previous in thread | raw e-mail
Philipp Ost wrote: > On 11/2/25 02: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. > > ksh93 from ports (shells/ksh93) does not. I guess my answer was ambiguous, "does" here was meant to be "does behave that way", i.e. "does not print ^C when editing the line". >>> Perhaps three decades. As far back as I can recall and that includes >>> using paper terminals. It may be the libedit library there has a borked >>> way of dealing with a SIGINT.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7b3acdda-0837-4cb6-a94c-ea79cabef6c6>