On 2020-04-06 18:42, Koichi Murase wrote:
This is fixed in the devel branch. See the following patch.
https://lists.gnu.org/archive/html/bug-bash/2020-01/msg00037.html
Indeed it is. Thank you for the information and patch. I apologize for
overlooking this message in my searches.
Key sequences containing backslashes are bound incorrectly (and
impossibly):
■ bind '"\C-\\": undo'
■ LC_ALL=C bind -q undo
undo can be invoked via "\C-x\C-u", "\C-\\\".
Is this a bug? Perhaps there is a reason I do not see. Thank you.
■ grep -i version -m 1 /usr/share/doc/readline/READ
On 2019-11-04 14:41, Chet Ramey wrote:
If \ef and Alt+f generate distinct character sequences, you can bind
them separately. If they don't, you can't. This has nothing to do with
whether or not incremental searching expands keyboard macros.
In that case, how would one go about binding æ such
On 2019-10-30 13:40, Chet Ramey wrote:
Incremental search doesn't do macro translation like that.
I see. Is this considered a shortcoming?
Being able to bind \ef and Alt+f to different commands in various programs
is useful, but without bash coming along for the ride, I might have to
go b
Moreover, the history search should be closed when the cursor is moved
(e.g. as with the left arrow key bound to backward-char), but the cursor
does not move (even with “æ” bound directly to forward-word).
Given the following binding...
"æ": "\ef"
... should not pressing “æ” during a history search end the search--the
same as pressing Escape followed by “f”? This does not happen with
5.0.3 (screencast attached).
Thank you.
On 2019-03-21 20:14, Chet Ramey wrote:
Thanks for the report. The /dev/fd version of this code needs to reap
process substitutions a little more often. It can't be *too* aggressive,
since the fds can still be read even after the process generating the
data has terminated, but it can do a little m
Hello. Running the attached demonstration script results in the following
errors, but I do not understand why:
./tmof: redirection error: cannot duplicate fd: Too many open files
./tmof: cannot make pipe for process substitution: Too many open files
./tmof: line 19: <( find "$d" -type f ): Too
On 2019-02-19 10:41, Greg Wooledge wrote:
On Sun, Feb 17, 2019 at 08:07:06PM -0500, Chet Ramey wrote:
On 2/16/19 11:38 AM, sunnycemet...@gmail.com wrote:
There are mixed behaviors. The idea behind the bash behavior is that a
null string added to a non-empty word is simply discarded, and this hap
I would like to include a null string as part of a parameter expansion word:
mapfile -t${bNullDelimited+d ''}
When bNullDelimited is set, I expect this to expand to:
mapfile -td ''
However, it expands to:
mapfile -td
Note that a lone null string is successfully expanded:
mapfile -t${
10 matches
Mail list logo
