Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
On 11/4/14, 5:16 PM, Piotr Grzybowski wrote: > Chet: for reasons unexplained calls to read_history_range at > > history.def:219 > 219 result = read_history_range (filename, history_lines_in_file, > -1); > > return more and more records (77824 is above my HISTFILESIZE): > > 1: history_lines_in_file = 77824 > > the loop at histfile.c:269 in read_history_range is the one that hangs. > code at > commit ca6a2ba40c709c2b45a56e49d21d0dfc66e21974 > Date: Sun Oct 5 19:12:20 2014 -0400 I still can't reproduce it on OS X 10.10: (1)$ ./bash --rcfile bashrc (2)$ echo $BASH_VERSION 4.3.30(22)-release (2)$ ls -l $HISTFILE -rw--- 1 chet staff 402 Nov 5 08:49 history-file (2)$ wc -l < $HISTFILE 20 (2)$ echo $HISTSIZE $HISTFILESIZE 50 50 (2)$ for (( i = 0; i < 30 ; i++ )); do history -a ; history -n ; done (2)$ wc -l < $HISTFILE 25 (2)$ tail $HISTFILE ls ls exit PROMPT_COMMAND='history -a ; history -n' PROMPT_COMMAND='history -a ; history -n' echo $BASH_VERSION ls -l $HISTFILE wc -l < $HISTFILE echo $HISTSIZE $HISTFILESIZE for (( i = 0; i < 30 ; i++ )); do history -a ; history -n ; done (2)$ i=0; while [ $i -lt 30 ]; do history -a ; history -n; let i++; done (2)$ wc -l < $HISTFILE 28 (2)$ tail $HISTFILE PROMPT_COMMAND='history -a ; history -n' PROMPT_COMMAND='history -a ; history -n' echo $BASH_VERSION ls -l $HISTFILE wc -l < $HISTFILE echo $HISTSIZE $HISTFILESIZE for (( i = 0; i < 30 ; i++ )); do history -a ; history -n ; done wc -l < $HISTFILE tail $HISTFILE i=0; while [ $i -lt 30 ]; do history -a ; history -n; let i++; done There are issues with keeping track of the number of lines currently in the history file, but those occur at the boundary conditions where the number of commands in the history list approaches $HISTFILESIZE. That doesn't explain your results. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Shellshock-vulnerable version still most obvious on ftp.gnu.org
If you go to ftp://ftp.gnu.org/pub/gnu/bash/, the most obvious most recent version of bash is this: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3.tar.gz ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3.tar.gz.sig The shellshock fix is hidden in a subdirectory: ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/ This is not mentioned on the main bash webpage here: http://www.gnu.org/software/bash/ Could there please be a new full tarball release of the patched version ? Thanks, Ian.
Re: Shellshock-vulnerable version still most obvious on ftp.gnu.org
On 11/05/2014 01:35 PM, Ian Jackson wrote: > If you go to ftp://ftp.gnu.org/pub/gnu/bash/, the most obvious most > recent version of bash is this: > ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3.tar.gz > ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3.tar.gz.sig > The shellshock fix is hidden in a subdirectory: > ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/ > > This is not mentioned on the main bash webpage here: > http://www.gnu.org/software/bash/ > > Could there please be a new full tarball release of the patched > version ? There has never been a full tarball release of any other official patch; so I'm not holding my breath that Chet's release process is going to change. However, making it more obvious on the main webpage that EVERY tarball needs to be augmented by the current set of official patches would be a worthwhile improvement to that web page. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Shellshock-vulnerable version still most obvious on ftp.gnu.org
On Wed, Nov 05, 2014 at 03:20:13PM +0100, Eric Blake wrote: > On 11/05/2014 01:35 PM, Ian Jackson wrote: > > Could there please be a new full tarball release of the patched > > version ? > > There has never been a full tarball release of any other official patch; There is a tarball of bash 3.2.48. Presumably because that was the "last" 3.x version at the time (though there have been subsequent 3.2.x patches, even before shellshock).
Re: Shellshock-vulnerable version still most obvious on ftp.gnu.org
On 11/5/14, 7:35 AM, Ian Jackson wrote: > If you go to ftp://ftp.gnu.org/pub/gnu/bash/, the most obvious most > recent version of bash is this: > ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3.tar.gz > ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3.tar.gz.sig > The shellshock fix is hidden in a subdirectory: > ftp://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/ > > This is not mentioned on the main bash webpage here: > http://www.gnu.org/software/bash/ > > Could there please be a new full tarball release of the patched > version ? This is from tiswww.case.edu/~chet/bash/bashtop.html: A downloadable tar file of the current version with all official patches applied is available from savannah. (The link is to http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-master.tar.gz). I cannot change the main bash webpage to include that text. I will put tarballs with patches in the usual places within a few days. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
On Wed, Nov 5, 2014 at 2:57 PM, Chet Ramey wrote: > I still can't reproduce it on OS X 10.10: [..] not only I cannot reproduce it at the moment, but also I have reached the following state (user: root): # cat .bash_history ls -al #1415144153 ls -al .bash_history #1415144154 pwd #1415144159 rm .bash_history #1415144161 cd #1415144163 pwd #1415144165 rm .bash_history #1415144171 i=0; while [ $i -lt 64 ]; do history -a; history -n; let i++; done; # ls -alh .bash_history -rw--- 1 root wheel 9.0M Nov 5 22:59 .bash_history # du -sh .bash_history 9.0M.bash_history # hexdump -C .bash_history 6c 73 20 2d 61 6c 20 0a 23 31 34 31 35 31 34 34 |ls -al .#1415144| 0010 31 35 33 0a 6c 73 20 2d 61 6c 20 2e 62 61 73 68 |153.ls -al .bash| 0020 5f 68 69 73 74 6f 72 79 20 0a 23 31 34 31 35 31 |_history .#14151| 0030 34 34 31 35 34 0a 70 77 64 0a 23 31 34 31 35 31 |44154.pwd.#14151| 0040 34 34 31 35 39 0a 72 6d 20 2e 62 61 73 68 5f 68 |44159.rm .bash_h| 0050 69 73 74 6f 72 79 20 0a 23 31 34 31 35 31 34 34 |istory .#1415144| 0060 31 36 31 0a 63 64 0a 23 31 34 31 35 31 34 34 31 |161.cd.#14151441| 0070 36 33 0a 70 77 64 0a 23 31 34 31 35 31 34 34 31 |63.pwd.#14151441| 0080 36 35 0a 72 6d 20 2e 62 61 73 68 5f 68 69 73 74 |65.rm .bash_hist| 0090 6f 72 79 20 0a 23 31 34 31 35 31 34 34 31 37 31 |ory .#1415144171| 00a0 0a 69 3d 30 3b 20 77 68 69 6c 65 20 5b 20 24 69 |.i=0; while [ $i| 00b0 20 2d 6c 74 20 36 34 20 5d 3b 20 64 6f 20 68 69 | -lt 64 ]; do hi| 00c0 73 74 6f 72 79 20 2d 61 3b 20 68 69 73 74 6f 72 |story -a; histor| 00d0 79 20 2d 6e 3b 20 6c 65 74 20 69 2b 2b 3b 20 64 |y -n; let i++; d| 00e0 6f 6e 65 3b 0a 00 00 00 00 00 00 00 00 00 00 00 |one;| 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 00902b60 which puzzles me a bit. Now I lost even all my while-loop commands! :) Graham: did you actually logout and removed the history file, and therefore started fresh? Sorry I guess I lost track of what is going on here. cheers, pg
Re: Odd bash behaviour with time:
On Tue, Nov 4, 2014 at 1:24 AM, Ángel González wrote:
>
> There are more syntax errors equivalent to the "time;" case: [..]
I completely agree with Linda :)
> time | foo
this one can be got rid of by the following (it will make time | time
| time | time; possible, very much like having spam-with-spam-on-spam.
since there is no flags |= $1; in this rule, the timings will not kick
in. really meaningless:)):
diff --git a/parse.y b/parse.y
index 815db98..dc345cd 100644
--- a/parse.y
+++ b/parse.y
@@ -1208,6 +1208,10 @@ pipeline_command: pipeline
$2->flags |= $1;
$$ = $2;
}
+ | timespec '|' pipeline_command
+ {
+$$ = $3;
+ }
| timespec list_terminator
{
ELEMENT x;
cheers,
pg
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
> On 6 Nov 2014, at 9:11 am, Piotr Grzybowski wrote: > > On Wed, Nov 5, 2014 at 2:57 PM, Chet Ramey wrote: >> I still can't reproduce it on OS X 10.10: [..] > > not only I cannot reproduce it at the moment, but also I have reached > the following state (user: root): > > # cat .bash_history > ls -al > #1415144153 > ls -al .bash_history > #1415144154 > pwd > #1415144159 > rm .bash_history > #1415144161 > cd > #1415144163 > pwd > #1415144165 > rm .bash_history > #1415144171 > i=0; while [ $i -lt 64 ]; do history -a; history -n; let i++; done; > > # ls -alh .bash_history > -rw--- 1 root wheel 9.0M Nov 5 22:59 .bash_history > > # du -sh .bash_history > 9.0M.bash_history > > # hexdump -C .bash_history > 6c 73 20 2d 61 6c 20 0a 23 31 34 31 35 31 34 34 |ls -al .#1415144| > 0010 31 35 33 0a 6c 73 20 2d 61 6c 20 2e 62 61 73 68 |153.ls -al .bash| > 0020 5f 68 69 73 74 6f 72 79 20 0a 23 31 34 31 35 31 |_history .#14151| > 0030 34 34 31 35 34 0a 70 77 64 0a 23 31 34 31 35 31 |44154.pwd.#14151| > 0040 34 34 31 35 39 0a 72 6d 20 2e 62 61 73 68 5f 68 |44159.rm .bash_h| > 0050 69 73 74 6f 72 79 20 0a 23 31 34 31 35 31 34 34 |istory .#1415144| > 0060 31 36 31 0a 63 64 0a 23 31 34 31 35 31 34 34 31 |161.cd.#14151441| > 0070 36 33 0a 70 77 64 0a 23 31 34 31 35 31 34 34 31 |63.pwd.#14151441| > 0080 36 35 0a 72 6d 20 2e 62 61 73 68 5f 68 69 73 74 |65.rm .bash_hist| > 0090 6f 72 79 20 0a 23 31 34 31 35 31 34 34 31 37 31 |ory .#1415144171| > 00a0 0a 69 3d 30 3b 20 77 68 69 6c 65 20 5b 20 24 69 |.i=0; while [ $i| > 00b0 20 2d 6c 74 20 36 34 20 5d 3b 20 64 6f 20 68 69 | -lt 64 ]; do hi| > 00c0 73 74 6f 72 79 20 2d 61 3b 20 68 69 73 74 6f 72 |story -a; histor| > 00d0 79 20 2d 6e 3b 20 6c 65 74 20 69 2b 2b 3b 20 64 |y -n; let i++; d| > 00e0 6f 6e 65 3b 0a 00 00 00 00 00 00 00 00 00 00 00 |one;| > 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 00902b60 > > which puzzles me a bit. > Now I lost even all my while-loop commands! :) > Graham: did you actually logout and removed the history file, and > therefore started fresh? Sorry I guess I lost track of what is going > on here. I did. We in terms of “logout”, I had a singe terminal session open. I unlinked the history file and then ctrl-Dd that last session to close it. When I created a new one, it was created and empty. > > cheers, > pg
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
Just out of curiosity, this mechanism is obviously something of a work around to give bash a single shared history in the same style as ksh had. Has there ever been any thought of providing a mechanism to support a single history session in a more native way? I know that zsh has the setopt share_history option to provide this (as I’ve tried this before finding I can’t get on with zsh for other reasons). Is there something about the way the history works in bash that makes it difficult to implement? > On 6 Nov 2014, at 9:11 am, Piotr Grzybowski wrote: > > On Wed, Nov 5, 2014 at 2:57 PM, Chet Ramey wrote: >> I still can't reproduce it on OS X 10.10: [..] > > not only I cannot reproduce it at the moment, but also I have reached > the following state (user: root): > > # cat .bash_history > ls -al > #1415144153 > ls -al .bash_history > #1415144154 > pwd > #1415144159 > rm .bash_history > #1415144161 > cd > #1415144163 > pwd > #1415144165 > rm .bash_history > #1415144171 > i=0; while [ $i -lt 64 ]; do history -a; history -n; let i++; done; > > # ls -alh .bash_history > -rw--- 1 root wheel 9.0M Nov 5 22:59 .bash_history > > # du -sh .bash_history > 9.0M.bash_history > > # hexdump -C .bash_history > 6c 73 20 2d 61 6c 20 0a 23 31 34 31 35 31 34 34 |ls -al .#1415144| > 0010 31 35 33 0a 6c 73 20 2d 61 6c 20 2e 62 61 73 68 |153.ls -al .bash| > 0020 5f 68 69 73 74 6f 72 79 20 0a 23 31 34 31 35 31 |_history .#14151| > 0030 34 34 31 35 34 0a 70 77 64 0a 23 31 34 31 35 31 |44154.pwd.#14151| > 0040 34 34 31 35 39 0a 72 6d 20 2e 62 61 73 68 5f 68 |44159.rm .bash_h| > 0050 69 73 74 6f 72 79 20 0a 23 31 34 31 35 31 34 34 |istory .#1415144| > 0060 31 36 31 0a 63 64 0a 23 31 34 31 35 31 34 34 31 |161.cd.#14151441| > 0070 36 33 0a 70 77 64 0a 23 31 34 31 35 31 34 34 31 |63.pwd.#14151441| > 0080 36 35 0a 72 6d 20 2e 62 61 73 68 5f 68 69 73 74 |65.rm .bash_hist| > 0090 6f 72 79 20 0a 23 31 34 31 35 31 34 34 31 37 31 |ory .#1415144171| > 00a0 0a 69 3d 30 3b 20 77 68 69 6c 65 20 5b 20 24 69 |.i=0; while [ $i| > 00b0 20 2d 6c 74 20 36 34 20 5d 3b 20 64 6f 20 68 69 | -lt 64 ]; do hi| > 00c0 73 74 6f 72 79 20 2d 61 3b 20 68 69 73 74 6f 72 |story -a; histor| > 00d0 79 20 2d 6e 3b 20 6c 65 74 20 69 2b 2b 3b 20 64 |y -n; let i++; d| > 00e0 6f 6e 65 3b 0a 00 00 00 00 00 00 00 00 00 00 00 |one;| > 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 00902b60 > > which puzzles me a bit. > Now I lost even all my while-loop commands! :) > Graham: did you actually logout and removed the history file, and > therefore started fresh? Sorry I guess I lost track of what is going > on here. > > cheers, > pg
Re: [PATCH] bracketed paste support
On 10/29/2014 08:49 PM, Chet Ramey wrote: >> On 10/27/14, 6:35 PM, Daniel Colascione wrote: >>> This patch adds support for "bracketed paste mode" to readline. In >>> this mode, readline instructs the terminal to wrap pasted strings in >>> special control sequences so that programs can distinguish them from >>> typed input. >> >> Thanks for the contribution. I'll look at the code; the approach seems >> sound. > > It went in very easily, though I changed some things around. This > will be in the next release of bash and readline. The code appeared in the snapshot, so I was able to look at how you "changed some things around". You removed the code that tries to determine whether a terminal actually supports the feature; instead, you blindly send the enable sequence to *any* terminal when enable-bracketed-paste is enabled, with potentially unknown consequences on those terminals. There's a comment in the code that indicates you expect users to enable the feature only on terminals where it's supported. I don't think it's reasonable to expect people to maintain a terminal database in their inputrc files. You also know very well that people are going to just set the feature to enabled in their configurations, test it, and see it work, all without considering whether they should enable this feature in a terminal-type-dependent conditional. Then they'll wonder why parts of their system silently break. Please restore the part of my patch, rl_bracketed_paste_probably_supported, that detects terminal support for this feature. signature.asc Description: OpenPGP digital signature
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
On 11/4/14 5:16 PM, Piotr Grzybowski wrote: > Chet: for reasons unexplained calls to read_history_range at > > history.def:219 > 219 result = read_history_range (filename, history_lines_in_file, > -1); > > return more and more records (77824 is above my HISTFILESIZE): There is an issue with this particular, relatively infrequent, set of circumstances: 1. HISTFILESIZE > HISTSIZE 2. Actual size of the history file > HISTSIZE 3. history list contains HISTSIZE entries 4. the user executes a sequence of `history -a; history -n'. Even `history -a; history -r' would probably prevent this, at the cost of more malloc/free operations. In this case, history_lines_in_file (which, despite its name, is supposed to keep track of how many lines bash has read from the history file) is calculated incorrectly. The result is that bash reads way too many lines from the history file each time. There are a couple of ways to fix it: one that uses facilities the history library provides today and one that changes the history library to expose the values more directly. One will appear in the next snapshot. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
On 11/5/14 8:39 PM, Graham Jones wrote: > Just out of curiosity, this mechanism is obviously something of a work > around to give bash a single shared history in the same style as ksh had. > Has there ever been any thought of providing a mechanism to support a > single history session in a more native way? I know that zsh has the > setopt share_history option to provide this (as I’ve tried this before > finding I can’t get on with zsh for other reasons). Is there something > about the way the history works in bash that makes it difficult to implement? In theory, one could change the functions in history.c and histfile.c to change the in-memory history list to one that uses a file, possibly with mmap(). I'd be happy to look at contributed code to do this, but implementing it is not high on the list. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
Thanks Chet. Couple of notes: 1) I’m not setting HISTFILESIZE, only HISTSIZE. HISTFILESIZE is getting set for me based on my choice of HISTSIZE (though I assume this is something that bash does that you know about). 2) As mentioned in the initial bug report, if I set PROMPT_COMMAND='history -a; history -r’ in my profile, my terminal was immediately hanging on initialisation. Since reseting the history file though, this no longer seems to be the case. > On 6 Nov 2014, at 1:25 pm, Chet Ramey wrote: > > On 11/4/14 5:16 PM, Piotr Grzybowski wrote: >> Chet: for reasons unexplained calls to read_history_range at >> >> history.def:219 >> 219 result = read_history_range (filename, history_lines_in_file, >> -1); >> >> return more and more records (77824 is above my HISTFILESIZE): > > There is an issue with this particular, relatively infrequent, set of > circumstances: > > 1. HISTFILESIZE > HISTSIZE > 2. Actual size of the history file > HISTSIZE > 3. history list contains HISTSIZE entries > 4. the user executes a sequence of `history -a; history -n'. Even > `history -a; history -r' would probably prevent this, at the cost > of more malloc/free operations. > > In this case, history_lines_in_file (which, despite its name, is supposed > to keep track of how many lines bash has read from the history file) is > calculated incorrectly. The result is that bash reads way too many lines > from the history file each time. > > There are a couple of ways to fix it: one that uses facilities the history > library provides today and one that changes the history library to expose > the values more directly. One will appear in the next snapshot. > > Chet > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer >``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [PATCH] bracketed paste support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/5/14 9:02 PM, Daniel Colascione wrote: > On 10/29/2014 08:49 PM, Chet Ramey wrote: >>> On 10/27/14, 6:35 PM, Daniel Colascione wrote: This patch adds support for "bracketed paste mode" to readline. In this mode, readline instructs the terminal to wrap pasted strings in special control sequences so that programs can distinguish them from typed input. >>> >>> Thanks for the contribution. I'll look at the code; the approach seems >>> sound. >> >> It went in very easily, though I changed some things around. This >> will be in the next release of bash and readline. > > The code appeared in the snapshot, so I was able to look at how you > "changed some things around". You removed the code that tries to > determine whether a terminal actually supports the feature; instead, you > blindly send the enable sequence to *any* terminal when > enable-bracketed-paste is enabled, with potentially unknown consequences > on those terminals. > > There's a comment in the code that indicates you expect users to enable > the feature only on terminals where it's supported. I don't think it's > reasonable to expect people to maintain a terminal database in their > inputrc files. People rarely use more than one, maybe two, different terminals or terminal emulators. I don't doubt that people who enable this feature know enough to figure out whether or not it's going to work. > Please restore the part of my patch, > rl_bracketed_paste_probably_supported, that detects terminal support for > this feature. It doesn't `detect terminal support' as such. It uses a heuristic to guess whether or not a terminal supports bracketed paste by checking for the presence of a string in another termcap sequence. Those kinds of heuristics always end up having an exception. - -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlRa30EACgkQu1hp8GTqdKsPvgCgnTgiPUAT27ADFyfZMErbr/F8 u+UAn1rYVN+4Ir/T+UEJEfLq2XO7fzvy =w6Rz -END PGP SIGNATURE-
Re: [PATCH] bracketed paste support
On 11/06/2014 02:38 AM, Chet Ramey wrote: > On 11/5/14 9:02 PM, Daniel Colascione wrote: >> On 10/29/2014 08:49 PM, Chet Ramey wrote: On 10/27/14, 6:35 PM, Daniel Colascione wrote: > This patch adds support for "bracketed paste mode" to readline. In > this mode, readline instructs the terminal to wrap pasted strings in > special control sequences so that programs can distinguish them from > typed input. Thanks for the contribution. I'll look at the code; the approach seems sound. >>> >>> It went in very easily, though I changed some things around. This >>> will be in the next release of bash and readline. > >> The code appeared in the snapshot, so I was able to look at how you >> "changed some things around". You removed the code that tries to >> determine whether a terminal actually supports the feature; instead, you >> blindly send the enable sequence to *any* terminal when >> enable-bracketed-paste is enabled, with potentially unknown consequences >> on those terminals. > >> There's a comment in the code that indicates you expect users to enable >> the feature only on terminals where it's supported. I don't think it's >> reasonable to expect people to maintain a terminal database in their >> inputrc files. > > People rarely use more than one, maybe two, different terminals or > terminal emulators. I don't doubt that people who enable this feature > know enough to figure out whether or not it's going to work. You're assuming users are experts. In reality, users are going to just paste "set enable-bracketed-paste on" into their inputrc files; they'll then see an inscrutable control sequence appear in places they didn't expect and have no idea what's wrong with their system. Please optimize for what real users actually do, not what perfectly intelligent users with perfect understanding of their systems would ideally do. I'm already going to have to contact every readline and bash distributor on earth and ask them to enable this feature by default. I don't want to have to ask them to apply a code patch too. >> Please restore the part of my patch, >> rl_bracketed_paste_probably_supported, that detects terminal support for >> this feature. > > It doesn't `detect terminal support' as such. It uses a heuristic to > guess whether or not a terminal supports bracketed paste by checking for > the presence of a string in another termcap sequence. Those kinds of > heuristics always end up having an exception. I don't think they will in this case, and at least it's a *conservative* heuristic. All terminals I've tested (urxvt, xterm, linux, and vte) either fail the heuristic, pass the heuristic and ignore the control sequence (which is harmless), or pass the heuristic and enable bracketed paste mode. Terminal emulation at this point is very mature. I don't expect significant development of new terminal types and new kinds of terminal emulators. The heuristic should work well for a long time. signature.asc Description: OpenPGP digital signature
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
On Nov 6, 2014 3:25 AM, "Chet Ramey" wrote: > > On 11/4/14 5:16 PM, Piotr Grzybowski wrote: > > Chet: for reasons unexplained calls to read_history_range at [..] > > There is an issue with this particular, relatively infrequent, set of > circumstances [..] > Thanks a lot Chet, seems that this was exactly what happened, although, at the moment, I cannot reproduce it. I can git revert to my previous .bash_history :) and then try again. It also would seem that what Graham sees is something differrent. > There are a couple of ways to fix it: one that uses facilities the history > library provides today and one that changes the history library to expose > the values more directly. One will appear in the next snapshot. thanks a lot! pg
