Re: Readline Documentation

On Fri, Sep 13, 2024 at 3:24 PM Chet Ramey wrote: > > > I considered that maybe it > > would only do this in response to being set directly, but neither > > ~/.bashrc nor /etc/bash.bashrc on my system include it, nor any other > > file I can find. Unless this has been changed between that version

Re: Readline Documentation

On 9/14/24 2:45 PM, G. Branden Robinson wrote: At 2024-09-13T15:24:15-0400, Chet Ramey wrote: It has no effects in its default state. If you don't change it, nothing happens. If you change it, you change `bell-style' instead. The fact that its usage continues suggests documenting it as depreca

Re: Readline Documentation

At 2024-09-13T15:24:15-0400, Chet Ramey wrote: > It has no effects in its default state. If you don't change it, nothing > happens. If you change it, you change `bell-style' instead. > > > The fact that its usage continues suggests documenting it as > > deprecated would be beneficial. > > Maybe.

Re: Readline Documentation

On 9/13/24 11:00 AM, John Devin wrote: As you said, it's been deprecated -- and undocumented -- for over 30 years (and remains only for backwards compatibility). There's no reason to document it. I understand it's been superseded, but I do want to point this out: running `bind -v` in bash 5.2

Re: Readline Documentation

Hey Chet, Thanks for getting back so fast. Just a couple points to make. On Thu, Sep 12, 2024 at 4:38 PM Chet Ramey wrote: > > On 9/11/24 3:19 PM, John Devin wrote: > > While hunting down some problems on a terminal, I ran across the > > option 'prefer-visible-bell'. It took me some time looking

Re: Readline Documentation

On 9/11/24 3:19 PM, John Devin wrote: Hello all, Sorry in advance if this is poorly formatted; I used plain-text mode in gmail but who knows if that works properly. It looks just fine. While hunting down some problems on a terminal, I ran across the option 'prefer-visible-bell'. It took me

Re: readline: double free when using PageDown

On 11/25/23 8:19 PM, Grisha Levit wrote: On Sat, Nov 25, 2023, 14:03 Chet Ramey > wrote: On 11/25/23 11:41 AM, Matthias Klose wrote: > [forwarded from https://bugs.debian.org/1056314 ] > > """ > I am gett

Re: readline: double free when using PageDown

On 26.11.23 02:19, Grisha Levit wrote: On Sat, Nov 25, 2023, 14:03 Chet Ramey wrote: On 11/25/23 11:41 AM, Matthias Klose wrote: [forwarded from https://bugs.debian.org/1056314] """ I am getting a crash in the Python REPL in this scenario: 1. start "python3" in a terminal 2. type "2+2", ent

Re: readline: double free when using PageDown

On Sat, Nov 25, 2023, 14:03 Chet Ramey wrote: > On 11/25/23 11:41 AM, Matthias Klose wrote: > > [forwarded from https://bugs.debian.org/1056314] > > > > """ > > I am getting a crash in the Python REPL in this scenario: > > > > 1. start "python3" in a terminal > > 2. type "2+2", enter > > 3. type

Re: readline: double free when using PageDown

On 11/25/23 11:41 AM, Matthias Klose wrote: [forwarded from https://bugs.debian.org/1056314] """ I am getting a crash in the Python REPL in this scenario: 1. start "python3" in a terminal 2. type "2+2", enter 3. type (or copy-paste) "1234+5678", enter 4. arrow-up, remove "234", page-down, arrow

Re: readline: remove redisplay in `rl_display_search`

On 7/11/22 1:05 PM, Frédéric Moulins wrote: Avoid a double redisplay when using reverse incremental search for example. `rl_message` already calls `(*rl_redisplay_function)` before returning, in all cases (`USE_VARARGS` or not). Thanks for the report. Chet -- ``The lyf so short, the craft so

Re: readline 'unix-filename-rubout' whitespace bug

On 8/27/21, 5:22 PM, Dabrien 'Dabe' Murphy wrote: On 8/27/21, 4:09 PM, Chet Ramey wrote: That circumstance is a pathname consisting solely of one or more slashes, separated from the previous word by whitespace. I'll fix it. The code has been like this since January, 2004. That's pretty dated.

Re: readline 'unix-filename-rubout' whitespace bug

On 8/27/21, 4:09 PM, Chet Ramey wrote: Thanks for the report. That circumstance is a pathname consisting solely of one or more slashes, separated from the previous word by whitespace. I'll fix it. Awesome! :-D PS — Another pathological test case is, e.g.: ls / / / // The code has

Re: readline 'unix-filename-rubout' whitespace bug

On 8/26/21 10:18 PM, d...@dabe.com wrote: Bash Version: 5.1 Patch Level: 8 Release Status: release Description: The manpage for bash(1) says: unix-filename-rubout Kill the word behind point, ***USING WHITE SPACE AND THE SLASH CHARACTER AS THE WOR

Re: readline crash with custom .inputrc

On 1/26/21 7:33 AM, Matthias Klose wrote: This was reported for Debian in https://bugs.debian.org/968703 for the interactive Python interpreter, however I also see it with gdb, e.g. trying to run ls in gdb. readline 8.1 is in use. This one has been around ever since the callback code came in in

Re: readline crash with custom .inputrc

2021年1月26日(火) 20:34 Matthias Klose : > This was reported for Debian in https://bugs.debian.org/968703 for the > interactive Python interpreter, > [...] > just hitting return in interactive mode triggers the segfault. Reduced-Case: $ cat .inputrc "\ra": self-insert $ python3 Python 3.7.7 (default,

Re: Readline history bug

On 1/31/20 3:32 PM, A via Bug reports for the GNU Bourne Again SHell wrote: > The readline package doesn't return the errno for some errors in > write_history, append_history, and history_truncate_file. > This caused an error in the CPython interpreter(at exit time) when the > .python_history fil

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

On 12/3/19 1:43 PM, Алексей Шилин wrote: > PS1='\[\e]0;тестоваястрока\a\]test prompt\$ ' This is really the problem: the invisible multibyte characters in the prompt are not correctly counted in all cases and throw off the cursor positioning calculations. That problem is worse when the prompt comp

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

В Ср, 27/11/2019 в 20:29 -0500, Chet Ramey пишет: > I poked around enough and found the cause. There will be a > fix in the next devel branch push. The first issue with the line not being cleared is indeed fixed. Thanks! The second one with incorrect history entry output position after e.g. End i

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

On 11/27/19 3:19 PM, Алексей Шилин wrote: > В Ср, 27/11/2019 в 11:48 -0500, Chet Ramey пишет: >> The reason I ask is that I can (unsurprisingly) reproduce multiple >> redisplay issues if the newline after the `\h:' is present, but none >> when $PS1 doesn't contain any newlines. > > You mean you ca

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

В Ср, 27/11/2019 в 20:29 -0500, Chet Ramey пишет: > I poked around enough and found the cause. There will be a > fix in the next devel branch push. That's awesome! Thank you *very* much!

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

В Ср, 27/11/2019 в 11:48 -0500, Chet Ramey пишет: > The reason I ask is that I can (unsurprisingly) reproduce multiple > redisplay issues if the newline after the `\h:' is present, but none > when $PS1 doesn't contain any newlines. You mean you can't reproduce the issue? That's weird, since I can

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

> Debian's /etc/skel/.bashrc contains these lines: > > if [ "$color_prompt" = yes ]; then > > PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m > \]:\[\033[01;34m\]\w\[\033[00m\]\$ > ' > else > PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ ' > fi > > The leading

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

On 11/27/19 11:24 AM, Алексей Шилин wrote: В Ср, 27/11/2019 в 11:02 -0500, Chet Ramey пишет: On 11/25/19 10:05 AM, Алексей Шилин wrote: Bash Version: 5.0 Patch Level: 11 Release Status: release Description: I'm using the following PS1 prompt (Debian's default for normal users): \[\e]0;\u@\h

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

В Ср, 27/11/2019 в 11:02 -0500, Chet Ramey пишет: > On 11/25/19 10:05 AM, Алексей Шилин wrote: > > > Bash Version: 5.0 > > Patch Level: 11 > > Release Status: release > > > > Description: > > > > I'm using the following PS1 prompt (Debian's default for normal > > users): > > > > \[\e]0;\u@\h: >

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

On Wed, Nov 27, 2019 at 11:02:49AM -0500, Chet Ramey wrote: > On 11/25/19 10:05 AM, Алексей Шилин wrote: > > I'm using the following PS1 prompt (Debian's default for normal users): > > > > \[\e]0;\u@\h: > > \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\ > > ]:\[\033[01;34m

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

On 11/25/19 10:05 AM, Алексей Шилин wrote: Bash Version: 5.0 Patch Level: 11 Release Status: release Description: I'm using the following PS1 prompt (Debian's default for normal users): \[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\ ]:\[\033[01;34m\]\w\[

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

On Tue, Nov 26, 2019, 9:50 AM Алексей Шилин wrote: > В Вт, 26/11/2019 в 07:35 -0600, Dennis Williamson пишет: > > You have printable characters enclosed. For example, \u. _Each_ > > sequence of unprintable characters needs to be separately enclosed > > _without_ enclosing the printable ones. > >

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

В Вт, 26/11/2019 в 07:35 -0600, Dennis Williamson пишет: > You have printable characters enclosed. For example, \u. _Each_ > sequence of unprintable characters needs to be separately enclosed > _without_ enclosing the printable ones. > > The first part of your prompt is what needs to be corrected.

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

В Вт, 26/11/2019 в 07:35 -0600, Dennis Williamson пишет: > You have printable characters enclosed. For example, \u. _Each_ > sequence of unprintable characters needs to be separately enclosed > _without_ enclosing the printable ones. They're all part of the escape sequence. Try: printf '\e]0;hell

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

On Tue, Nov 26, 2019 at 07:35:09AM -0600, Dennis Williamson wrote: > On Tue, Nov 26, 2019, 5:46 AM Алексей Шилин wrote: > > And they *are* enclosed: PS1='\[\e]0;\u@\h: \w\a\]${debian_chroot... > > You have printable characters enclosed. For example, \u. _Each_ sequence of > unprintable characters

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

On Tue, Nov 26, 2019, 5:46 AM Алексей Шилин wrote: > В Пн, 25/11/2019 в 18:29 -0800, L A Walsh пишет: > > Multi-byte or not, invisible characters need to be enclosed > > as documented under 'PROMPTING': > > > > \[ begin a sequence of non-printing characters, which could > >

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

В Пн, 25/11/2019 в 18:29 -0800, L A Walsh пишет: > Multi-byte or not, invisible characters need to be enclosed > as documented under 'PROMPTING': > > \[ begin a sequence of non-printing characters, which could > be used to embed a terminal control sequence into the >

Re: [readline] Multibyte invisible chars cause weird prompt length calculation issue

On 2019/11/25 07:05, wrote: > # As you see, now everything works as expected i.e. the issue seems > # to be in the way readline is handling multibyte invisible characters > # in a prompt, *probably* in the rl_redisplay() function. > Multi-byte or not, invisible characters need to

Re: readline: How to unbind _all_ keys

On 24/05/2019 17:16, Chet Ramey wrote: That's not in the distributed version of bash-5.0. If you're applying an older cygwin patch, have you tried just building the distributed version? Let's make sure that works. Bang! It does. So sorry that I didn't have that idea myself. Especially as I ha

Re: readline: How to unbind _all_ keys

On 5/24/19 10:51 AM, Henning wrote: > On 22/05/2019 15:30, Chet Ramey wrote: >> >> What error message did you get when trying to compile bash-5.0? I don't >> have or use cygwin, so you'll probably have to go to the cygwin bash >> maintainer, but we can at least try to point him in the right directi

Re: readline: How to unbind _all_ keys

On 22/05/2019 15:30, Chet Ramey wrote: What error message did you get when trying to compile bash-5.0? I don't have or use cygwin, so you'll probably have to go to the cygwin bash maintainer, but we can at least try to point him in the right direction. I tried to compile several times, but al

Re: readline: How to unbind _all_ keys

On 5/21/19 5:33 PM, Dennis Williamson wrote: > On Tue, May 21, 2019 at 3:04 AM Henning wrote: > >> On 20/05/2019 15:38, Chet Ramey wrote: >>> On 5/19/19 10:43 AM, Henning wrote: I don't like to have dozens of key bindings I never use. Currently I am issuing lots of lots of bind -r/-u co

Re: readline: How to unbind _all_ keys

On 22/05/2019 14:58, Koichi Murase wrote: What still remains is the not working assignment of ^X. Henning Hi, I guess you are using Bash 4.4 because, according to my records, bind -x '"\C-x": ...' after unbinding all the keyseqs causes segfaults in Bash-3.0, 3.1 and 4.0--4.2, infinite loops in

Re: readline: How to unbind _all_ keys

On 5/22/19 4:47 AM, Henning wrote: > On 21/05/2019 16:16, Chet Ramey wrote: >> >> I can't reproduce this using bash-5.0. I took your script, ran it, then >> bound C-x to execute "echo abc": > [snip] >> And hitting ^X gives me "abc". It doesn't matter whether or not I remove >> the binding for \C-x

Re: readline: How to unbind _all_ keys

> What still remains is the not working assignment of ^X. > > Henning Hi, I guess you are using Bash 4.4 because, according to my records, bind -x '"\C-x": ...' after unbinding all the keyseqs causes segfaults in Bash-3.0, 3.1 and 4.0--4.2, infinite loops in Bash 3.2, and error messages like "bash

Re: readline: How to unbind _all_ keys

On 21/05/2019 23:33, Dennis Williamson wrote: Why don't you unbind the keystrokes that are actually bound? while read -r b; do bind -r "$b"; done < <(bind -p | awk -F ':' '/./ && !/self-insert|accept-line|^#/ {gsub("\"", "", $1); print $1}') That was my first approach when I dealt with this som

Re: readline: How to unbind _all_ keys

On 21/05/2019 16:16, Chet Ramey wrote: I can't reproduce this using bash-5.0. I took your script, ran it, then bound C-x to execute "echo abc": [snip] And hitting ^X gives me "abc". It doesn't matter whether or not I remove the binding for \C-x itself. I started a console and changed nothing

Re: readline: How to unbind _all_ keys

On Tue, May 21, 2019 at 3:04 AM Henning wrote: > On 20/05/2019 15:38, Chet Ramey wrote: > > On 5/19/19 10:43 AM, Henning wrote: > >> I don't like to have dozens of key bindings I never use. Currently I > >> am issuing lots of lots of bind -r/-u commands to get rid of the > >> default bindings. Th

Re: readline: How to unbind _all_ keys

On 5/21/19 4:04 AM, Henning wrote: > And another problem: after removing all \C-x sequences I used bind -x > to bind a shell command to \C-x proper. The result, when hitting \C-x, > is the following error message: > > bash_execute_unix_command: cannot find keymap for command > > Using a sequ

Re: readline: How to unbind _all_ keys

On 20/05/2019 15:38, Chet Ramey wrote: On 5/19/19 10:43 AM, Henning wrote: I don't like to have dozens of key bindings I never use. Currently I am issuing lots of lots of bind -r/-u commands to get rid of the default bindings. This slows down console startup unnecessarily. I would really like t

Re: readline: How to unbind _all_ keys

On 5/19/19 10:43 AM, Henning wrote: > I don't like to have dozens of key bindings I never use. Currently I > am issuing lots of lots of bind -r/-u commands to get rid of the > default bindings. This slows down console startup unnecessarily. > > I would really like to have an inputrc command like $

Re: readline: How to unbind _all_ keys

On 20/05/2019 07:41, G. Branden Robinson wrote: Remember that "self-insert" is a binding. I know (I've been using for over 20 years (v2.01) now) If you removed all bindings, no keystrokes would do _anything_. that's exactly what I want in order to then only bind the keys I want to have boun

Re: readline: How to unbind _all_ keys

At 2019-05-19T16:43:41+0200, Henning wrote: > I don't like to have dozens of key bindings I never use. Currently I > am issuing lots of lots of bind -r/-u commands to get rid of the > default bindings. This slows down console startup unnecessarily. > > I would really like to have an inputrc comman

Re: Readline bug?

On 1/23/19 5:49 AM, Greg Bell wrote: > Thanks for the quick help guys, much appreciated. Weird/annoying problem, > but at least it's known, and the workaround's fine. That behavior has been there in this form for around 25 years. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer

Re: Readline bug?

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

Re: Readline bug?

On 1/21/19 10:01 PM, Greg Bell wrote: > > Hi Chet et al, > > 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. Thanks for the report. This has been there forever. The default readline vi command-mode keymap has ^E bound to switch to emacs e

Re: readline fails to understand options.

On 12/28/18 10:54 PM, Bize Ma wrote: > > > Sure, it's a candidate for inclusion in a future version. I wouldn't > object > if someone wanted to do a sample implementation, since it changes how the > variable value is parsed. > > > I only wish I knew enough C to make any (even small

Re: readline fails to understand options.

> > Sure, it's a candidate for inclusion in a future version. I wouldn't object > if someone wanted to do a sample implementation, since it changes how the > variable value is parsed. > I only wish I knew enough C to make any (even small) positive recommendation.

Re: readline fails to understand options.

On 12/21/18 12:52 AM, Bize Ma wrote: > This works: > >      $ bind 'set enable-bracketed-paste on'; bind -v | grep 'bracketed' > set enable-bracketed-paste on > > However, almost any variation of the parameter "on" is not understood by > readline: > > $ bind 'set enable-bracketed-paste

Re: Readline documentation error

On 5/25/18 9:50 PM, Jorge Maldonado Ventura wrote: > There is an unnecessary closing parenthesis under /bracketed-paste-begin > ()/ from section 8.4.3 of /Bash Reference Manual/ Thanks for the report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vi

Re: readline-8.0-alpha: Makefile.in: don't forget to create pkgconfigdir

> >> Thanks for the report. I think a better fix is to not to attempt to > >> install readline.pc if $(pkgconfigdir) is missing. > > > > Why not? If you are doing an install into DESTDIR for the purpose of > > bundling a pre-built binary for a distro, then $(pkgconfigdir) will be > > missing, bec

Re: readline-8.0-alpha: Makefile.in: don't forget to create pkgconfigdir

On 5/24/18 2:29 PM, Eric Blake wrote: > On 05/24/2018 01:18 PM, Chet Ramey wrote: >> On 5/24/18 11:40 AM, gabriele balducci wrote: >>> hi >>> >>> just tried to build/install readline-8.0-alpha and found the following >>> glitch: >> >> Thanks for the report. I think a better fix is to not to attempt

Re: readline-8.0-alpha: Makefile.in: don't forget to create pkgconfigdir

On 05/24/2018 01:29 PM, Eric Blake wrote: On 05/24/2018 01:18 PM, Chet Ramey wrote: On 5/24/18 11:40 AM, gabriele balducci wrote: hi just tried to build/install readline-8.0-alpha and found the following glitch: Thanks for the report. I think a better fix is to not to attempt to install read

Re: readline-8.0-alpha: Makefile.in: don't forget to create pkgconfigdir

On 05/24/2018 01:18 PM, Chet Ramey wrote: On 5/24/18 11:40 AM, gabriele balducci wrote: hi just tried to build/install readline-8.0-alpha and found the following glitch: Thanks for the report. I think a better fix is to not to attempt to install readline.pc if $(pkgconfigdir) is missing. Wh

Re: readline-8.0-alpha: Makefile.in: don't forget to create pkgconfigdir

On 5/24/18 11:40 AM, gabriele balducci wrote: > hi > > just tried to build/install readline-8.0-alpha and found the following > glitch: Thanks for the report. I think a better fix is to not to attempt to install readline.pc if $(pkgconfigdir) is missing. Chet -- ``The lyf so short, the craft s

Re: Readline macro definition with multibyte characters

On 2/4/17 9:07 PM, Grisha Levit wrote: > The character-search command accepts multibyte characters just fine, but > when reading input from a macro, multibyte characters are not processed > correctly. For example trying to invoke the macro defined with: > > bind '"\C-f": "\C-]π"' > > will fail to

Re: Readline

On Sat, Sep 24, 2016 at 6:16 PM, Gerard Seibert wrote: > Out of morbid curiosity, has a date been set for the release of > "readline-7.0"? I know that there is an "RC" version in the wild right > now. It's been released already. https://lists.gnu.org/archive/html/info-gnu/2016-09/msg00013.html

Re: Readline-7.0 Release available

Chet Ramey wrote: +== CHANGES == d. Readline's input handler now performs signal processing if read(2) is interrupted by SIGALRM or SIGVTALRM. --- It sounds like the ability for signal handlers to be called while waiting for input has been restored. h. Use psele

Re: readline doesn't refresh properly anymore

On Jun 2, 2016 11:25 AM, "Charles T. Smith" wrote: > > Hello, > > I moved from ubuntu 10.04 to 14.04 and now readline usually doesn't refresh > my command line when scrolling through my history - the last tokens are often > not shown until I move the cursor there. Is that due to a change in bash?

Re: readline doesn't refresh properly anymore

On 4/8/16 11:22 AM, Charles T. Smith wrote: > Hello, > > I moved from ubuntu 10.04 to 14.04 and now readline usually doesn't refresh > my command line when scrolling through my history - the last tokens are often > not shown until I move the cursor there. Is that due to a change in bash? There's

Re: readline and bash disagree on $'' quoting

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/5/15 3:52 PM, Daniel Colascione wrote: > Consider this command: > > foo $'foo \' bar' > > As far as the bash core is concerned, this command has one argument > word. But readline, for completion, splits it up into three words: > > 0: foo >

Re: readline and bash disagree on $'' quoting

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/5/15 3:52 PM, Daniel Colascione wrote: > Consider this command: > > foo $'foo \' bar' > > As far as the bash core is concerned, this command has one argument > word. But readline, for completion, splits it up into three words: > > 0: foo >

Re: readline-6.3: update config.h.in

On 4/20/15 2:59 AM, Andreas Schwab wrote: >>> +#undef __EXTENSIONS__ >>> +#undef _ALL_SOURCE >>> +#undef _GNU_SOURCE >>> +#undef _POSIX_SOURCE >>> +#undef _POSIX_1_SOURCE >>> +#undef _POSIX_PTHREAD_SEMANTICS >>> +#undef _TANDEM_SOURCE >>> + >> >> Readline configure.ac doesn't call AC_USE_SYSTEM_EX

Re: readline-6.3: update config.h.in

Chet Ramey writes: > On 4/19/15 2:00 PM, Andreas Schwab wrote: >> The config.h.in file in the standalone readline distribution is missing >> a lot of templates. It should really be generated by autoheader. >> >> --- readline-6.3/config.h.in.~1~ 2012-01-18 16:22:13.0 +0100 >> +++ rea

Re: readline-6.3: update config.h.in

On 4/19/15 2:00 PM, Andreas Schwab wrote: > The config.h.in file in the standalone readline distribution is missing > a lot of templates. It should really be generated by autoheader. > > --- readline-6.3/config.h.in.~1~ 2012-01-18 16:22:13.0 +0100 > +++ readline-6.3/config.h.in 2015

Re: readline 6.3 violates POSIX by doing #undef setjmp

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/6/15 4:50 PM, Eric Blake wrote: > ./lib/readline/libreadline.a(util.o): In function `rl_abort_internal': > /home/eblake/bash/lib/readline/util.c:115: undefined reference to > `siglongjmp' > collect2: error: ld returned 1 exit status > > You need

Re: readline 6.3 violates POSIX by doing #undef setjmp

On 01/23/2015 04:31 PM, Eric Blake wrote: > Thus, the following is the minimal patch for Cygwin to have correct > compilation (both setjmp and setjmp_nosigs usage points in bash will > have identical behavior). Although I still think that you ought to fix > more than just Cygwin by auditing and e

Re: readline 6.3 violates POSIX by doing #undef setjmp

On 01/23/2015 03:53 PM, Eric Blake wrote: > On 01/23/2015 02:58 PM, Eric Blake wrote: >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/setjmp.html is >> clear: >> >> "It is unspecified whether setjmp() is a macro or a function. If a macro >> definition is suppressed in order to access a

Re: readline 6.3 violates POSIX by doing #undef setjmp

On 01/23/2015 02:58 PM, Eric Blake wrote: > http://pubs.opengroup.org/onlinepubs/9699919799/functions/setjmp.html is > clear: > > "It is unspecified whether setjmp() is a macro or a function. If a macro > definition is suppressed in order to access an actual function, or a > program defines an ext

Re: readline 6.3 bug report

On 3/7/14 2:25 AM, Daan van Rossum wrote: > Hi Chet, > > Readline 6.3 has a new bug in vi-mode: > the "." command does no longer redo the latest "dw", "dl", "D", ... commands. > > Reverting back to version 6.2 fixed the issue for me. Thanks for the report. It's the result of an overzealous atte

Re: readline display bug with UTF-8 and char insertion

On 1/21/13 3:16 PM, Egmont Koblinger wrote: > Hi, > > On a fully UTF-8 environment, in certain easily reproducible cases, the > command line becomes messed up (the cursor ends up in the wrong column, and > from then on it's tons of cumulative mistakes). I'm using bash-4.2.42, but > the bug also a

Re: readline display bug with UTF-8 and char insertion

Hi Chet, Friendly ping - could you please look at this bug and patch, too? I know it's bit more complicated, and I haven't finished the non-UTF part, but based on my findings I believe this should be really straightforward for you. I know bash's UTF-8 support is contributed code and is quite com

Re: readline expansion: 'cp $v/' -> 'cp \$v/' (no expansion) - why?

On 7/8/12 4:14 PM, Jason Vas Dias wrote: >> There is already code -- commented out -- to export array variables in >> a format that resembles a compound array assignment, and code -- still >> commented out -- in bash to understand them. It's not enabled because >> the chance for obscure collision

Re: readline expansion: 'cp $v/' -> 'cp \$v/' (no expansion) - why?

On Sun, Jul 8, 2012 at 5:50 PM, Chet Ramey wrote: > On 7/7/12 11:39 AM, Jason Vas Dias wrote: > >> Next Question : >> - any plans to allow us to export array or associative store >> variables ? ie. represent them in *environ passed to programs >> with an integration with glibc "getenv()"

Re: readline expansion: 'cp $v/' -> 'cp \$v/' (no expansion) - why?

On 7/7/12 11:39 AM, Jason Vas Dias wrote: > Next Question : > - any plans to allow us to export array or associative store > variables ? ie. represent them in *environ passed to programs > with an integration with glibc "getenv()" to support this ? There is already code -- commented out

Re: readline expansion: 'cp $v/' -> 'cp \$v/' (no expansion) - why?

Sorry, I tried 4.2-29(2) at home and it DOES correctly complete '$SRC/' - of courrse, it helps if $SRC contains the name of an existing directory, which it did not at work. Thanks ! a most interesting list . Next Question : - any plans to allow us to export array or associative store variabl

Re: readline expansion: 'cp $v/' -> 'cp \$v/' (no expansion) - why?

On 7/5/12 7:59 AM, Jason Vas Dias wrote: > hi Eric - thanks for your response, but bash-4.2.29(2), just built from > latest patches from gnu on x86_64 ubuntu, does NOT > "restore the old behavior" , but now refuses to tab-expand at > all - 'cat $SRC/' on the command line still produces no > output

Re: readline expansion: 'cp $v/' -> 'cp \$v/' (no expansion) - why?

hi Eric - thanks for your response, but bash-4.2.29(2), just built from latest patches from gnu on x86_64 ubuntu, does NOT "restore the old behavior" , but now refuses to tab-expand at all - 'cat $SRC/' on the command line still produces no output. Is there some option I need to give to enable it

Re: readline expansion: 'cp $v/' -> 'cp \$v/' (no expansion) - why?

On 07/05/2012 04:58 AM, Jason Vas Dias wrote: > Now it changes the input string into > 'less \$SRC/' and prevents tab expansion > as would be done without use of any variables. > Would anyone know how to restore the old behavior > with bash 4.2.2 + readline 6.2 (linux ubuntu 12.04) ? Yep - upgrad

Re: Readline fencepost error with long prompt

Chet Ramey writes: > Try the attached patch. It should fix the problem without introducing any > regressions. Looks good, I couldn't find any regressions. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for s

Re: Readline fencepost error with long prompt

Andreas Schwab wrote: > Configuration Information [Automatically generated, do not change]: > Machine: powerpc > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='powerpc-suse-linux-gnu' > -DCONF_VENDOR='su

Re: Readline redisplay bug with long prompt

Andreas Schwab wrote: > Bash Version: 3.2 > Patch Level: 48 > Release Status: release > > Description: > Redisplay fails if the prompt wraps around and contains invisible > characters after the wrap point. > > Repeat-By: > (assuming 80 column display) > $ > PS1='

Re: Readline : move to previous/next path component

On 2008-10-16, Larry Clapp <[EMAIL PROTECTED]> wrote: > On Thu, Oct 16, 2008 at 09:12:23AM +, Andre Majorel wrote: >> On 2008-10-16, Aharon Robbins <[EMAIL PROTECTED]> wrote: >> > In article <[EMAIL PROTECTED]>, >> > Andre Majorel <[EMAIL PROTECTED]> wrote: >> >>Vi mode would help, but in Bash

Re: Readline : move to previous/next path component

On Thu, Oct 16, 2008 at 09:12:23AM +, Andre Majorel wrote: > On 2008-10-16, Aharon Robbins <[EMAIL PROTECTED]> wrote: > > In article <[EMAIL PROTECTED]>, > > Andre Majorel <[EMAIL PROTECTED]> wrote: > >>Vi mode would help, but in Bash, there's no way to switch between > >>it and Emacs mode on

Re: Readline : move to previous/next path component

On 2008-10-16, Aharon Robbins <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, > Andre Majorel <[EMAIL PROTECTED]> wrote: >>Vi mode would help, but in Bash, there's no way to switch >>between it and Emacs mode on the fly. > > Au contraire: > > set -o vi > set -o emacs By "

Re: Readline : move to previous/next path component

In article <[EMAIL PROTECTED]>, Andre Majorel <[EMAIL PROTECTED]> wrote: >Vi mode would help, but in Bash, there's no way to switch >between it and Emacs mode on the fly. Au contraire: set -o vi set -o emacs -- Aharon (Arnold) Robbins arnold AT sk

Re: Readline : move to previous/next path component

On 2008-10-15, Chet Ramey <[EMAIL PROTECTED]> wrote: >> On 2008-10-15, Chet Ramey <[EMAIL PROTECTED]> wrote: >> > Andre Majorel wrote: >> >> One frequently needed function that readline does not seem to >> >> have is a way to move to the beginning of the next or previous >> >> path component. >> >

Re: Readline : move to previous/next path component

> On 2008-10-15, Chet Ramey <[EMAIL PROTECTED]> wrote: > > Andre Majorel wrote: > >> One frequently needed function that readline does not seem to > >> have is a way to move to the beginning of the next or previous > >> path component. > > > > Readline doesn't have any built-in knowledge of Unix pa

Re: Readline : move to previous/next path component

On 2008-10-15, Chet Ramey <[EMAIL PROTECTED]> wrote: > Andre Majorel wrote: >> One frequently needed function that readline does not seem to >> have is a way to move to the beginning of the next or previous >> path component. > > Readline doesn't have any built-in knowledge of Unix pathnames. For

Re: Readline : move to previous/next path component

Andre Majorel wrote: > One frequently needed function that readline does not seem to > have is a way to move to the beginning of the next or previous > path component. This is what I've come up with : > > \C-t: "\C-b\C-b\e\C-]/\C-f" > \C-y: "\C-]/\C-f" Readline doesn't have any built-in knowl

Re: readline in read -e and dynamic-complete-history problems

[EMAIL PROTECTED] wrote: > Repeat-By: > Run the above program. Hit Tab, note the partial completion to the first > ambiguous portion of the history. Type any letter to from the urls list to > disambiguate and hit Tab again. No additional completion occurs. > > Also, try ^N or ^P to cycle throu

Re: readline/history cvs?

Sam Steingold wrote: Where is the readline/history cvs (or git or whatever) repository? There is no public cvs repository. to keep the clisp readline module up to date with the current readline/history releases, I would like to be able to get a diff between readline.h & history.h from readli

Re: readline does not always redraw line very well

Jan Engelhardt wrote: Bash Version: 3.2 Patch Level: 25 Release Status: release Description:/Repeat-By: Having a prompt with color definitions makes readline reposition the cursor wrong on many occassions. Here is one of them. export PS1="\[\e[1;30m\]\A \[\e[0;32m\]\h:\w \[\e[1;37m\]>\[\e[0m\]

Re: readline escaping problems

> i have an install of a recent version of readline (5.2.007) / bash (3.2.25) > which is causing problems with horizontal scrolling positioning because of > escape sequences in my PS1 prompt. It looks like bash32-028 contains a fix for this problem. In the future, you might consider providing a v

  1   2   >