On 11/4/15 1:48 PM, Keith Thompson wrote:
> Thanks, I didn't know about history-expand-line.
>
> Is there some case where shell-expand-line would actually be useful?
> If I've typed *"foo bar"*, I can't think of any case where I'd *want*
> it to be replaced by *foo bar*, which has a very different
On Thu, Nov 05, 2015 at 06:45:45PM -0600, Dennis Williamson wrote:
> red=$(tput setaf 1)
> none=$(tput sgr0)
> greet='\[$red\]Hello\[$none\]'
> printf '%s\n' "${greet@P}"
> echo -e "${greet@P}"
> read -e -p "${greet@P}"
>
> Naively stripping the delimiters in this case would leave $redHELLO$none
>
On 11/5/15 7:45 PM, Dennis Williamson wrote:
> That's what the \[ and \] escape sequences expand to and use to
> communicate information to readline about invisible characters in the
> prompt (RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE). If you want to
> use the expansion of
And today I learned that there's an "undo" command! (It's bound to
Ctrl-X Ctrl-U and to Ctrl-_ by default.) Thanks, that's incredibly useful.
I still can't think of a case where I'd want quote removal, which changes
the meaning of the line, but I don't have to use it.
On Fri, Nov 6, 2015 at 5:
Hi,
While testing bash with address sanitizer I discovered a heap out of
bounds read. This affects bash 4.3 with the latest patchlevel 42.
Triggering this bug only seems to work with a US keyboard layout. It
gets triggered by pressing shift+alt+7.
I don't know why this is happening, this keycode
Hanno Böck writes:
> Triggering this bug only seems to work with a US keyboard layout. It
> gets triggered by pressing shift+alt+7.
> I don't know why this is happening, this keycode combination doesn't
> have any function on an us keyboard.
This is generating M-& of course, which is bound to ti
