Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15628 > unrolled thread

Re: Fwd: Don't set $?=130 when discarding the current command line (not run yet) with CTRL-C?

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Fwd: Don't set $?=130 when discarding the current command line (not run yet) with CTRL-C? Robert Elz <kre@munnari.OZ.AU> - 2019-11-23 16:50 +0700

#15628 — Re: Fwd: Don't set $?=130 when discarding the current command line (not run yet) with CTRL-C?

    Date:        Fri, 22 Nov 2019 16:16:58 +0800
    From:        Clark Wang <dearvoid@gmail.com>
    Message-ID:  <CADv8-ogRv-atdWkiRNWdVA=V03XKpq4AF1-pDTmc=PmKUiHK_w@mail.gmail.com>

  | Curious why people care about this?

For some people it seems to be related to wanting to see $? in their
prompt, and either have it explicit that a SIGINT interrupted command
entry, or continue with previous $? ..

For me it is partly just because of what $? is.  From posix:

	? Expands to the decimal exit status of the most recent pipeline
	  (see Section 2.9.2).

nothing about being altered by anything other than (at least attempted)
execution of a pipeline (ie: some command or other).

More practically, the times when I want it are when I have run a command,
then start typing the next one, and realise that I really meant to check
the exit status of the last one before running another.   If I finish typing
my next command I just mentally curse my forgetfulness, and take whatever
action I can (often re-running the previous command, if that makes sense).
But if I catch it before I have finished the next command, I have the
opportunity to abort what I'm doing, and check $? before it is lost.

If that happens while still on the first (or only) line of the new command,
then a line kill char (^U often) is OK, deletes whatever I typed, and I
can replace that with "echo $?" or whatever.

But if it happens after a \n has been entered, that no longer works,
whereas SIGINT (^C usually) does:

Compare bash...

jinx$ false
jinx$ while sleep 3
do
^C
jinx$ echo $?
130

(in bash my PS2 is set to be (become really) invisible so I can cut/paste
whole command sequences)

to the NetBSD sh (where editline doesn't handle my PS2 "properly")

[jinx]{2}$ false
[jinx]{2}$ while sleep 3
> do
> 
[jinx]{2}$ echo $?
1
[jinx]{2}$ true
[jinx]{2}$ while sleep 3
> do
> 
[jinx]{2}$ echo $?
0

(there was a ^C, not echoed explicitly, after the PS2 prompt on the line
after each "do" ... the lack of the echo another difference between editline
and readline I assume, the ^C is echoed if I disable editline and just
use the tty driver, my PS2 also works as planned then).

[jinx]{2}$ set +V
[jinx]{2}$ true
[jinx]{2}$ while sleep 3
do
^C
[jinx]{2}$ echo $?
0

kre

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web