Re: bash 4.4.18 return to new line

[Alexander Kozlenkov]

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/
>

Re: SIGSEGV: rl_redisplay: Long Directory Name with EM Dash character in Graphical Terminal

[Kieran Grant]

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

Documentation improvement: add missing comma

[Jorge]

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: 6k buffer bug in shells

[Chet Ramey]

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/

Re: bash 4.4.18 return to new line

[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/

Re: bash 4.4.18 return to new line

[Alexander Kozlenkov]

$ 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

[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: Feature request: tab completion on functions

[Chet Ramey]

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: Feature request: tab completion on functions

[Odne Hellebø]

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/

bash 4.4.18 return to new line

[Alexander Kozlenkov]

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

6k buffer bug in shells

[Sten Westerback]

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

Re: SIGSEGV: rl_redisplay: Directory with EM Dash

[Kieran Grant]

> 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

Re: SIGSEGV: rl_redisplay: Long Directory Name with EM Dash character in Graphical Terminal

[Chet Ramey]

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/