When executing shell commands bound to key sequences with bind -x, the
initial line(s) of multiple line shell prompts and/or commands are left
intact; when the prompt is redisplayed, the initial line(s) are output
again, causing the appearance of duplicate lines. This seems to be due to
the co
On Tue, 22 Jan 2019, Greg Bell wrote:
On bash 4.3.48 (Ubuntu 16.04), \C-e doesn't work to move me to the end of
line when in vi command mode.
This is specific to bash, and has been the case for as long as I can
remember. I thought I'd reported it, but maybe not...
As a workaround, in .bash
On Mon, 21 Dec 2015, Chet Ramey wrote:
My position is that a feature like this is not popular enough to be made
the default, and the way to move forward and make something like it
available is to make it a configurable option. The standard way to do
that is to make it an option in config-top.h,
On Tue, 22 Dec 2015, Fotis Georgatos wrote:
Compare bash vs zsh:
http://blog.flowblok.id.au/static/images/shell-startup-actual.png # if
you have similar diagram for your distro, please post! fi. HPC systems
rely on environment modules [1] and bash is still particularly tricky
while using it,
On Sun, 12 Mar 2017, Grisha Levit wrote:
For example:
$ PS1='\w $(echo \w) $ '
~ /home/levit $
This seems to work as documented, for the same reason this happens:
╶➤ echo ~
/home/rob
The expansion order is perhaps non-obvious: the prompt string backslash
escapes are replaced before the str
The attached script will provoke an occasional loss of a single byte when
the read builtin is used with a timeout. Output will eventually look
something like this after a failure:
x: ab (2)
x: cd (2)
x: ef (2)
x: g (1)
x: hi (2)
x: j (1)
x: l (1)
x: mn (2)
x: op (2)
x: q (1)
x: rs (2)
x: tu (2
Prompted (pun intended) by the recent thread on detecting missing newlines
in command output, I'd had another look at my own version, and discovered
a potential issue with control characters being written as-is in declare
output. Minimal (harmless) reproducer:
╶➤ x () { echo $'\e[31m'"oops"$'
On Sun, 19 Mar 2023, Grisha Levit wrote:
When HISTTIMEFORMAT is set and history file truncation is performed,
the first line of the history file (i.e. the timestamp of the first
entry) seems to always be missing
/tmp/hist
HISTTIMEFORMAT= HISTFILESIZE=3 HISTFILE=/tmp/hist bash --norc -in <<<$'
