Re: SIGSEGV: rl_redisplay: Long Directory Name with EM Dash character in Graphical Terminal
On 2/1/18 5:48 PM, Kieran Grant wrote: > Hi All, > > Found an interesting bug today, > > GNU bash, version 4.4.18(4)-release (x86_64-unknown-linux-gnu) > > When running in a graphical terminal (xterm, mate-terminal, gnome-terminal) > set to 80x24. > I get a SIGSEGV in rl_redisplay doing the following: (Haven't managed to do > it on a Virtual Console) I can't reproduce it on Mac OS X or Red Hat, even when using the Debian prompt. What is your $PS1? (The value of `prompt' in the call to readline() in the trace looks kind of sketchy.) -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: SIGSEGV: rl_redisplay: Directory with EM Dash
> I'm Re-sending using bashbug (though sent through Thunderbird :/) after I've > subscribed to mailing-list, appears my first message didn't go through Nope, I was wrong. :/ Just was very much delayed
6k buffer bug in shells
Hi After trying to figure out what causes a weird bug, which i can see with lots of shells and connection types (local terminal on linux, ssh + numerous shells on AIX and putty (linux & windows)+numerous shells on AIX) i though i would ask makers of my favorite shell. The problem is that when i paste in longer texts instead of just typing the result isn't as expected. It seems that after a certain amount of characters the shell drops a few characters but then continues. The number of characters dropped depends on the line with (with 50 it's 4, with 64 it was 12 etc). And with slightly larger amounts of text there is also a pause before it continues while one would expect the flow to be continous with a simple task like this, Here is a simple file which when copied to clipboard and then pasted into a shell should produce the obvious text in /tmp/chartestRESULT.txt... but it just doesn't always. Here a result file sample with error shown at row starting with 3JJJ and 5WWW :: I have tried workarounds such as: - breaking into 6 k blocks to append to file - replacing cat >> file .. << homedocwith echo " ... \n ... \n ... \n" >> file - term=dumbwhich i first thought fixed it.. but later problem appeared. I didn't yet test to change terminal on all ssh levels. It seems that the shell or something involved, such as clipboard functionality or ssh protocol, doesn't like to be flooded by a couple of MB of text. Hope you can point me towards a fix or work-around. What i'm actually attempting is pasting in of Base64 encoded data, broken into 64 byte rows, as a simple way to transfer small binary files from a workstation to a host that is behind a longer chain of ssh sessions. This works perfectly for smaller files but then i noticed this problem. Here example of failing rows from row 140 forward: Input MUEOSDFqQMHIwCY9GQwKx2iiFQ/CFQb7d/pH0IWmdqs9PEHr4ZNPBnt4x9AzWl0ijz9nPlG7d1hd2MFZ /fpgXXdTXS8/D4yxCq0++IvzZJEdPKHjm4zaOdGY8fimhUbMngxadrEfp8rsQmP51/AFgujz8GdCu4DZ Rk60GmzrIBuZ8OODeOY2z+jZE01xEj5hYvl0FE0m8HLlKS2I5Ju9xWbWdCf0qXw9blL5XGb2/XvavTWT HRIJdtsKFK5jMUaTfDMPJidvp2Di6omIJc3Q8V/bisv9Juj3jAKBDZR+oc2SR6+C+MTqyzfMpWvTNp9P Result: MUEOSDFqQMHIwCY9GQwKx2iiFQ/CFQb7d/pH0IWmdqs9PEHr4ZNPBnt4x9AzWl0ijz9nPlG7d1hd2MFZ /fpgXXdTXS8/D4yxCq0++IvzZJEdPKHjm4zaOdGY8fimhUbMngxadrEfp8rsQmP51/AFgujz8GdCu4DZ Rk60GmzrIBuZ8OOD HRIJdtsKFK5jMUaTfDMPJidvp2Di6omIJc3Q8V/bisv9Juj3jAKBDZR+oc2SR6+C+MTqyzfMpWvTNp9P So something dropped the eOY2z+jZE01xEj5hYvl0FE0m8HLlKS2I5Ju9xWbWdCf0qXw9blL5XGb2/XvavTWT In this case after 141*81 + 64 = 11485 characters on 142nd row. Environment: 1: Redhat linux 2.6.32-696.6.3.el6.x86_64 #1 SMP Fri Jun 30 13:24:18 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux GNU Bash-4.1 GNOME Terminal 2.31.3 Environment 2: AIX 7.1.5.0 TL05 Putty Development snapshot 2017-06-21.d618974 (Windows 64 bit) - Sten Ellei edellä ole toisin mainittu: / Unless stated otherwise above: Oy IBM Finland Ab PL 265, 00101 Helsinki, Finland Business ID, Y-tunnus: 0195876-3 Registered in Finland cat > /tmp/chartestRESULT.txt << THEEND 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2
bash 4.4.18 return to new line
Hello! Thanks for your project! On days I did building bash v4.4.18 for using vi-ins-mode-string and vi-cmd-mode-string variables in VI mode (insert and command modes). But, when I print long string, line break don't work for the first input line: > (ins):15:30:03:sah4ez@PC001:~/git/bash-4.4.18$ > 1115:24:36:sah4ez@PC001:~/git/bash-4.4.18$ 11 When I print more symbols, line break work well. I'm experimented with size of the window, I calculated 11 symbols after of which began the output from first symbol of the line. But line break work well after line fills anew. -- Best regards, Alexandr Kozlenkov
Re: Feature request: tab completion on functions
Damn :) my email is in a changelog :D Thanks :) One thing though, is it possible to stop the cursor at the point it gets ambiguous? As in I have function foobar and fooBar if I do foo I will get foobar and if my intent was to execute fooBar I will have to go back and uppercase it. I think it would be better if you stopped at foo and gave the completion options there, then if I wrote b I'd get foobar or B I'd get fooBar. On 1 February 2018 at 21:50, Chet Ramey wrote: > On 2/1/18 3:40 PM, Odne Hellebø wrote: >> Is it something that you will consider adding to bash? I also saw something >> about the complete inbuilt command, is it possible through that? > > I already did, and the version in the devel branch can do it. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Feature request: tab completion on functions
On 2/2/18 6:18 AM, Odne Hellebø wrote: > Damn :) my email is in a changelog :D Thanks :) Credit where credit's due. > One thing though, is it possible to stop the cursor at the point it > gets ambiguous? As in I have function > foobar and fooBar if I do > foo I will get foobar and if my intent was to execute fooBar I > will have to go back and uppercase it. I think it would be better if > you stopped at foo and gave the completion options there, then if I > wrote b I'd get foobar or B I'd get fooBar. That's a kind of hybrid case-insensitivity that Readline has never supported. If you want completions to be treated without regard to case, Readline will take that all the way to considering multiple possible completions that differ only in case as identical. This is one of the things that would be helped by allowing programmable completion for command names, but we're not there yet. You could get some approximation of what you want by binding TAB to menu-complete, but that might be too disruptive to the rest of your environment. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: bash 4.4.18 return to new line
On 2/2/18 7:42 AM, Alexander Kozlenkov wrote: > Hello! > Thanks for your project! > On days I did building bash v4.4.18 for using vi-ins-mode-string and > vi-cmd-mode-string variables in VI mode (insert and command modes). > But, when I print long string, line break don't work for the first input > line: > > (ins):15:30:03:sah4ez@PC001:~/git/bash-4.4.18$ > > 1115:24:36:sah4ez@PC001:~/git/bash-4.4.18$ > 11 > > When I print more symbols, line break work well. What's your $PS1? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: bash 4.4.18 return to new line
$ printenv PS1 \e[1;95m\t\e[0m:\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ $ uname -a Linux PC001 4.8.0-58-generic #63~16.04.1-Ubuntu SMP Mon Jun 26 18:08:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux $ bash --version GNU bash, версия 4.4.18(1)-release (x86_64-unknown-linux-gnu) Copyright (C) 2016 Free Software Foundation, Inc. And today I connect to remote server via command: $ shh usern...@remote.server.com And when I navigate over history (in vi-mode press 'k' key) cursor position move after '@' and navigation to left position don't work. But when I press 'I' key (insert before first symbol of line) cursor position not change (after '@') and next I entering something or removed symbols, cursor position move to real position (first symbol in line). Example: $ ssh username@(*cursor here*)remote.server.com # press 'I' $ ssh username@(*cursor here*)remote.server.com # press right and remove first symbol $ (*cursor here*)sh usern...@remote.server.com -- Best regards Aleksandr Kozlenkov пт, 2 февр. 2018 г. в 22:13, Chet Ramey : > On 2/2/18 7:42 AM, Alexander Kozlenkov wrote: > > Hello! > > Thanks for your project! > > On days I did building bash v4.4.18 for using vi-ins-mode-string and > > vi-cmd-mode-string variables in VI mode (insert and command modes). > > But, when I print long string, line break don't work for the first input > > line: > > > (ins):15:30:03:sah4ez@PC001:~/git/bash-4.4.18$ > > > 1115:24:36:sah4ez@PC001:~/git/bash-4.4.18$ > > 11 > > > > When I print more symbols, line break work well. > > What's your $PS1? > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >
Re: bash 4.4.18 return to new line
On 2/2/18 2:39 PM, Alexander Kozlenkov wrote: > $ printenv PS1 > \e[1;95m\t\e[0m:\[\e]0;\u@\h: > \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ There are a bunch of invisible characters at the beginning of the prompt that aren't enclosed in \[ and \]. That will throw off the cursor location calculations. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: 6k buffer bug in shells
On 2/2/18 9:50 AM, Sten Westerback wrote: > Hi > > After trying to figure out what causes a weird bug, which i can see with > lots of shells and connection types (local terminal on linux, ssh + > numerous shells on AIX and putty (linux & windows)+numerous shells on AIX) > i though i would ask makers of my favorite shell. > > The problem is that when i paste in longer texts instead of just typing > the result isn't as expected. It seems that after a certain amount of > characters the shell drops a few characters but then continues. The number > of characters dropped depends on the line with (with 50 it's 4, with 64 it > was 12 etc). And with slightly larger amounts of text there is also a > pause before it continues while one would expect the flow to be continous > with a simple task like this, It's not quite as simple as you think. If you're pasting into an interactive shell without turning off line editing, you have to deal with the kernel turning character-at-a-time mode on and off for each line (and the single-character reads line editing requires). In the past, we've found that doing this causes characters to be discarded. This is part of the problem that `bracketed paste' mode was intended to address. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Documentation improvement: add missing comma
From 9.2 Bash History Builtin: > If @var{last} is not specified it is set to @var{first} Missing comma after the dependent clause. It should read: If @var{last} is not specified, it is set to @var{first} Grammar references: * https://www.ego4u.com/en/cram-up/writing/comma?10 * https://www.grammarly.com/blog/conditional-sentences/ * https://english.stackexchange.com/questions/6786/comma-in-conditional-sentence-and-in-antithesis
Re: SIGSEGV: rl_redisplay: Long Directory Name with EM Dash character in Graphical Terminal
He he, I love that on the mailing list archive it replaces my host details with "address@hidden", kinda ruins the calculations though... and it is in my screenshots. :D
Re: bash 4.4.18 return to new line
I changed my PS1 to: (cmd):09:37:53:sah4ez@PC001:~$ printenv PS1 \e[1;95m\t\]\e[0m:\]\e[0;92m\u@\h\]\e[0m:\]\e[0;34m\w\a\]\]\e[0m$ \] But line break still does not work: ff09:37:56:sah4ez@PC001:~$ f Else I have the file: $ cat ~/.inputrc set show-mode-in-prompt on set vi-ins-mode-string \1\e[32;1m\2(ins)\1\e[0m:\2 set vi-cmd-mode-string \1\e[34;1m\2(cmd)\1\e[0m:\2 If I removed this '~/.inpurtrc' file, and set to PS1: \t:\u@\h:\w\a$ Line break continues does not work: 7:05:sah4ez@PC001:~$ fff As you can see number of 'f' letters changed after which began input from start line. пт, 2 февр. 2018 г. в 22:41, Chet Ramey : > On 2/2/18 2:39 PM, Alexander Kozlenkov wrote: > > $ printenv PS1 > > \e[1;95m\t\e[0m:\[\e]0;\u@\h: > > \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@ > \h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ > > There are a bunch of invisible characters at the beginning of the prompt > that aren't enclosed in \[ and \]. That will throw off the cursor location > calculations. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >