Colored-character displayed on CTRL-C ?

Colored-character displayed on CTRL-C ?

[Larry Schrof]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

Recent versions of bash have this very nifty feature where, when you hit CTRL-C to terminate a command line and get a new prompt on a new line, something like ^C with a yellow background is displayed to help remind you that the command is not actually executed.

With my vision impairment, simply using the event number in my shell prompt is not sufficient. I'd really like ideas on the best way to tell zsh to display a character with a yellow background on CTRL-C, followed by taking me to a new prompt on the next line.

I'm speculating this would start by setting up a trap on the right signal?

Re: Colored-character displayed on CTRL-C ?

[Phil Pennock]

On 2013-09-23 at 17:37 +0000, Larry Schrof wrote:
> Recent versions of bash have this very nifty feature where, when you hit CTRL-C to terminate a command line and get a new prompt on a new line, something like ^C with a yellow background is displayed to help remind you that the command is not actually executed.
> 
> With my vision impairment, simply using the event number in my shell prompt is not sufficient. I'd really like ideas on the best way to tell zsh to display a character with a yellow background on CTRL-C, followed by taking me to a new prompt on the next line.
> 
> I'm speculating this would start by setting up a trap on the right signal?

Looking at the reason for the requirements, rather than the exact
requirement stated, would it be helpful to instead update your prompt to
show that the previous command was terminated with a signal, using a
long name instead of just a number?  In this sample below, the
"{SIGINT}" is in red:

-phil@redoubt:p1[11:55]17½(1006)~% sleep 3
^C
{SIGINT}-phil@redoubt:p1[12:07]17¼(1007)~% 

My prompt configuration includes:

  zmodload -i zsh/parameter || return 1
  function prompt_pdp_precmd {
    local exitstatus=$?
    emulate -L zsh  # ksh_arrays breaks us badly
    psvar=()
    # [...]
    psvar[1]=$exitstatus
    if [[ $exitstatus -ge 128 ]];   then psvar[1]=SIG${signals[$exitstatus-127]:-}
                                         [[ $psvar[1] == SIG ]] && psvar[1]=$exitstatus
    elif [[ $exitstatus -eq 127 ]]; then psvar[1]='127/CmdNotFound'         # SUSv4 XCU 2.8.2
    elif [[ $exitstatus -eq 126 ]]; then psvar[1]='126/CmdNotExecutable'    # SUSv4 XCU 2.8.2
    elif [[ $exitstatus -eq 125 ]]; then psvar[1]='125/GitBisectUntestable' # git
    fi
    # [... other stuff affecting psvar[2]..psvar[5]]
    return $exitstatus
  }

Then part of the prompt configuration would, in more modern zsh idiom,
include the string:

  %(?..%F{red}{%v}%f)

So, if and only if the last command exited non-true, show {exitstatus}
in the prompt, where that is a number if it was a non-signal exit, else
a signal name, and some common special-meanings also shown.

You could use psvar[2] to hold a colour name based upon the exitstatus,
and embed that in the prompt; just note that %2v is not expanded inside
a %F{...} so you would instead have to enable prompt_subst:

  setopt prompt_subst
  PS1='%(?..%F{$psvar[2]}%K{$psvar[3]}{%v}%k%f)%~%# '

That allows for psvar[2] holding a foreground colour and psvar[3]
holding a background colour.

% setopt prompt_subst
% psvar=(SIGINT red yellow); false; print -P '%(?..%F{$psvar[2]}%K{$psvar[3]}{%v}%k%f)%~%# '
{SIGINT}~% 

(where that is showing "{SIGINT}" in red text on a yellow background).

-Phil

Re: Colored-character displayed on CTRL-C ?

[Bart Schaefer]

On Sep 23,  5:37pm, Larry Schrof wrote:
}
} Recent versions of bash have this very nifty feature where, when you
} hit CTRL-C to terminate a command line and get a new prompt on a new
} line, something like ^C with a yellow background is displayed to help
} remind you that the command is not actually executed.

This should do it for you:

    autoload -Uz colors
    colors
    handle-interrupt() {
      print -n "$bg_bold[yellow]${(V)KEYS:-^C}$reset_color"
      zle -I && zle .kill-buffer
    }
    zle -N handle-interrupt
    TRAPINT() { zle && zle handle-interrupt }

You might also want to

    bindkey ^G handle-interrupt

to replace the built-in binding for send-break, but this behaves a bit
differently than send-break in some situations so use with caution.

The use of kill-buffer also pushes the line onto the kill ring, so you
can get it back with ^Y after interrupting it.  Perhaps that's a feature.

Re: Colored-character displayed on CTRL-C ?

[Phil Pennock]

On 2013-09-23 at 12:26 -0700, Phil Pennock wrote:
> Looking at the reason for the requirements, rather than the exact
> requirement stated,

My apologies, I misinterpreted the point at which you were pressing
Ctrl-C and my advice won't help at all.  Sorry.

Bart's answer is obviously correct.

-Phil

Re: Colored-character displayed on CTRL-C ?

[Hauke Petersen]

On Mon, Sep 23, 2013 at 7:37 PM, Larry Schrof <larrys@fb.com> wrote:
> I'd really like ideas on the best way to tell zsh to display a
> character with a yellow background on CTRL-C, followed by taking
> me to a new prompt on the next line.

One attempt:

    [[ -o interactive ]] && function TRAPINT {
        zle && print -nP '%B%S^C%s%b'
        return $(( 128 + $1 ))
    }

`[[ -o interactive ]]' is to only define the trap in interactive
shells. `zle && ...' to only print ^C when the line editor is active.
`print -P' interprets prompt escape codes. %B and %b mark bold, %S and
%s standout/invert. That's the same format as the default
PROMPT_EOL_MARK. You can find other formatting options (prompt
escapes) in zshmisc(1).

-- 
[Resending this, evil gmail tried to keep it off the list.]

Re: Colored-character displayed on CTRL-C ?

[Phil Pennock]

On 2013-09-23 at 13:02 -0700, Bart Schaefer wrote:
> This should do it for you:
> 
>     autoload -Uz colors
>     colors
>     handle-interrupt() {
>       print -n "$bg_bold[yellow]${(V)KEYS:-^C}$reset_color"
>       zle -I && zle .kill-buffer
>     }
>     zle -N handle-interrupt
>     TRAPINT() { zle && zle handle-interrupt }

This seems to interact poorly with vared, resulting in vared not being
left until enter is pressed, and the value of the variable being blanked
out as a result.  Also, in bck-i-search (^R) the prompt is re-shown,
and the mode is still in bck-i-search (although the current selected
value is blanked out, but typing continues the search).

It seems that handling these requires the TRAPINT to return non-zero,
but doing so interacts with the widget above to double-prompt (badly).

I like the widget (which is why I found these issues).  :)  Just can't
figure out how to fix these issues.

Ideally, I'd be able to set $? after this, so a manual invocation of
precmd would correct the prompt variables, since precmd() isn't invoked
normally, given that widget, whereas it is with a straight Ctrl-C
without TRAPINT (albeit with $? set to 1).

-Phil

Re: Colored-character displayed on CTRL-C ?

[Bart Schaefer]

On Sep 23,  2:10pm, Phil Pennock wrote:
}
} My apologies, I misinterpreted the point at which you were pressing
} Ctrl-C and my advice won't help at all.  Sorry.

Actually you're not that far off.  $? == 1 after interrupting ZLE with
the terminal interrupt character, so it is possible to have the prompt
show something instead of trapping the signal.  It's just not possible
to distinguish a command that was interrupted before it started from
one that exited with status 1 without doing some additional work.

E.g., you could test for $HISTNO having changed, or not, though that
gets tricky with HIST_IGNORE_DUPS.

Re: Colored-character displayed on CTRL-C ?

[Bart Schaefer]

On Sep 23,  3:00pm, Phil Pennock wrote:
} Subject: Re: Colored-character displayed on CTRL-C ?
}
} On 2013-09-23 at 13:02 -0700, Bart Schaefer wrote:
} > This should do it for you:
} > 
} >     autoload -Uz colors
} >     colors
} >     handle-interrupt() {
} >       print -n "$bg_bold[yellow]${(V)KEYS:-^C}$reset_color"
} >       zle -I && zle .kill-buffer
} >     }
} >     zle -N handle-interrupt
} >     TRAPINT() { zle && zle handle-interrupt }
} 
} This seems to interact poorly with vared

Hm, I wondered about that.  You can change the zle line in handle-interrupt
to read

    zle -I && zle .kill-buffer && zle .send-break

and maybe get better behavior that way.

} Also, in bck-i-search (^R) the prompt is re-shown,
} and the mode is still in bck-i-search (although the current selected
} value is blanked out, but typing continues the search).

I think send-break will help there, too, but in case not:

} It seems that handling these requires the TRAPINT to return non-zero,
} but doing so interacts with the widget above to double-prompt (badly).

You can check for [[ $CONTEXT == vared ]] in the TRAPINT function and
return nonzero when appropriate.  (It'll normally be unset outside of
ZLE.)

} Ideally, I'd be able to set $? after this, so a manual invocation of
} precmd would correct the prompt variables, since precmd() isn't invoked
} normally, given that widget, whereas it is with a straight Ctrl-C
} without TRAPINT (albeit with $? set to 1).

"zle .send-break" sets the internal error flags so normally it's just
like invoking "return 1" ... but you can use an "always" block to get
around that.