#49900 less: Can't set a binding for ^C

Package:
less
Source:
less
Description:
pager program similar to more
Submitter:
Date:
2025-07-07 21:55:01 UTC
Severity:
normal
#49900#5
Date:
1999-11-11 14:01:29 UTC
From:
To:
I think I should be able to make ctrl-C exit less by running:

$ echo '^C quit' | lesskey -

but ^C still just beeps at me.  If I put ^B or ^D in the lesskey file
instead, things work as expected.

#49900#8
Date:
1999-11-11 17:56:11 UTC
From:
To:
----- Forwarded message from bjh21@cam.ac.uk -----

Subject: Bug#49900: less: Can't set a binding for ^C
Reply-To: <bjh21@cam.ac.uk>, 49900@bugs.debian.org
From: <bjh21@cam.ac.uk>
To: submit@bugs.debian.org
X-Mailer: bug 3.1.7
Date:	Thu, 11 Nov 1999 14:01:29 +0000

Package: less
Version: 332-4.1

I think I should be able to make ctrl-C exit less by running:

$ echo '^C quit' | lesskey -

but ^C still just beeps at me.  If I put ^B or ^D in the lesskey file
instead, things work as expected.
----- End forwarded message -----
#49900#9
Date:
1999-11-13 07:44:54 UTC
From:
To:
Thomas Schoepf wrote:
less, but the ^C doesn't get read as a normal character.  So to have
less process ^C in a lesskey file as if it were a normal character would
be tricky.  ^C (or whatever you've set as your interrupt character via
stty) also has special functions in less, in that it interrupts any
lengthy operation, such as a search in progress, a line number
calculation, an F command, etc.  This allows the user to gain control,
to bring less back to the command prompt.  The only remotely reasonable
thing that could be done would be to treat ^C as a command character
when at the command prompt, but as the normal "interrupt" character when
not at the command prompt.  But this seems to introduce nasty race
conditions; if you press ^C during a search, it *might* interrupt the
search, but if the search happens to finish in the millisecond just
before you hit ^C, it will quit the program.  I understand the
motivation in this request; the SIGINT caused by ^C causes most programs
to just quit.  But for interactive programs, like vi, it doesn't act
that way, and IMHO, it shouldn't.  Let me know if you think there's
something better that could be done.
--Mark

#49900#14
Date:
1999-11-14 17:27:03 UTC
From:
To:
I can think of 3 possibilities:

1. Always execute the action that's bound to the SIGINT key, interrupting
   lengthy operations etc. if necessary.

2. Use SIGINT to interrupt lengthy operations and execute the bounded action
   only if there's nothing to interrupt.

3. Leave it like it is and document in lesskey's manpage that one cannot bind
   the key that produces a SIGINT to an action.

Personally, I'd tend to number 3. I think, the possibility to bind SIGINT to
any other operation than "quit" is probably not really useful. On the other
hand, quitting by pressing ^C would either render its
lengty-operation-interrupt useless or could lead to race conditions.

Maybe <bjh21@cam.ac.uk> can clarify his motivations?


Thanks
Thomas

#49900#19
Date:
1999-11-15 10:59:24 UTC
From:
To:
My motivation is actually that a user complained about it on a non-Debian
system, but I think I understand his reasoning.

He's used to using 'more', rather than less, and more behaves like most
non-interactive programs and exits on a SIGINT.  He would like less to
behave the same.

While I can see the race-conditions inherent in making a key have
different meanings depending on what less is doing at the time, this will
not be a problem for a user who (as I suspect is the case here) never
tries to use SIGINT to interrupt a long operation.  Thus, I think case 2
is probably best (though I'm checking with the user on this).

I suppose the problem here is that less is on the boundary between
interactive and non-interactive (especially when running with -EX), and
thus what behaviour is correct is non-obvious.