Browsing the history of commands. Inconsistency between Bash and Emacs

[Dani Moncayo]

Hello, Bash developers,

(I know little about Bash, so I apologize beforehand if I say
something inaccurate or nonsensical)

Bug #16740 was filed today against the Emacs package, asking to remove
an inconsistency between the keys employed by Emacs and Bash to browse
the history of commands.  See:

  http://lists.gnu.org/archive/html/bug-gnu-emacs/2014-02/msg01082.html

Emacs uses M-p/M-n to browse the minibuffer history (and C-p/C-n to
move to the previous/next line in a multi-line buffer), whereas Bash
uses C-n/C-p for browsing the command history (and doesn't use M-p/M-n
for anything, AFAIK).

It would be nice to remove this inconsistency (this is the obvious
part), and IMO TRT would be to make Bash behave like Emacs, that is:
1. Use M-p/M-n to browse the command history (instead of the current C-p/C-n).
2. Use C-p/C-n to move to the previous/next line, in the current
command being edited.

WDYT?

-- 
Dani Moncayo

Re: Please accept M-p as well as C-p

[Pierre Gaston]

On Thu, Feb 13, 2014 at 1:35 PM, Ed Avis  wrote:

> Bash accepts the Emacs keybinding C-p to go back in the history, and C-n
> to go forward.
> But most of the time in Emacs (when using its minibuffer) the keys you use
> are Meta-p
> and Meta-n, or on a modern PC keyboard Alt-p and Alt-n.
>
> Currently entering M-p at the bash prompt gives some control characters.
> It could more usefully go back in the history instead.  Then if you flip
> between GNU
> emacs and GNU bash you wouldn't keep typing the wrong thing.
>
> --
> Ed Avis 
>
>
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> __
>
>

You can add in your ~/.inputrc

"\ep": previous-history
"\en": next-history

Please accept M-p as well as C-p

[Ed Avis]

Bash accepts the Emacs keybinding C-p to go back in the history, and C-n to go 
forward.
But most of the time in Emacs (when using its minibuffer) the keys you use are 
Meta-p
and Meta-n, or on a modern PC keyboard Alt-p and Alt-n.

Currently entering M-p at the bash prompt gives some control characters.
It could more usefully go back in the history instead.  Then if you flip 
between GNU
emacs and GNU bash you wouldn't keep typing the wrong thing.

-- 
Ed Avis 


__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

Re: Please accept M-p as well as C-p

[Chet Ramey]

On 2/13/14 6:35 AM, Ed Avis wrote:
> Bash accepts the Emacs keybinding C-p to go back in the history, and C-n to 
> go forward.
> But most of the time in Emacs (when using its minibuffer) the keys you use 
> are Meta-p
> and Meta-n, or on a modern PC keyboard Alt-p and Alt-n.

I am not convinced that Alt-p and Alt-n are any more widely used than C-p
and C-n, but in any event, it's easy to bind whatever key sequence those
key combinations produce to the same editing functions as C-p and C-n.

I would further argue that the number of people using an emacs minibuffer
to run their shell commands is a small fraction of the total number of
bash users.  The folks doing that are more than capable of adding a key
binding or two.

> Currently entering M-p at the bash prompt gives some control characters.

Because that key sequence is unbound.  Take the key sequence that you see
and bind it to previous-history, e.g.,

"\e[A":previous-history

(where \e is ESC, or meta)

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: Please accept M-p as well as C-p

[Ed Avis]

Thanks for your reply.  I don't mean people running bash inside Emacs.
I just mean that when running bash standalone, you use C-p to go backwards
in the history, but when running Emacs standalone, you use Alt-p.

Since currently Alt-p doesn't do anything in bash, it could usefully be bound
to previous-history, so that those who flip back and forth between these
two GNU programs could keep using the same key sequence.

-- 
Ed Avis 

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

Re: Please accept M-p as well as C-p

[Chet Ramey]

On 2/13/14 10:20 AM, Ed Avis wrote:
> Thanks for your reply.  I don't mean people running bash inside Emacs.
> I just mean that when running bash standalone, you use C-p to go backwards
> in the history, but when running Emacs standalone, you use Alt-p.

Sure, I understand.  I also argue that the two programs use different
mental models.

> Since currently Alt-p doesn't do anything in bash, it could usefully be bound
> to previous-history, so that those who flip back and forth between these
> two GNU programs could keep using the same key sequence.

My point is that before making it the default, which ends up being
difficult to change, we try to get some data on whether or not that
would be the right default binding.  Maybe people who want that binding
could do it using the existing mechanisms and see how it works.

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: Please accept M-p as well as C-p

[Andreas Schwab]

Chet Ramey  writes:

> My point is that before making it the default, which ends up being
> difficult to change, we try to get some data on whether or not that
> would be the right default binding.  Maybe people who want that binding
> could do it using the existing mechanisms and see how it works.

There should at least be an easier way to move between lines of
multiline commands.  AIUI there is no readline command the moves
vertically within the commandline (in readline a line always includes
any embedded newlines).

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Invalid byte sequence under UTF-8 locale generates a segmentation fault when using printf %q (ansic_quote)

[Eduardo A . Bustamante López]

Using an invalid byte sequence with printf %q segfaults bash, for a
UTF-8 locale.

Here are the steps to reproduce the fault:

gdb local/bin/bash
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/dualbus/local/bin/bash...done.
(gdb) r ./invalid-utf8
Starting program: /home/dualbus/local/bin/bash ./invalid-utf8

Program received signal SIGSEGV, Segmentation fault.
0x004b4bc0 in ansic_quote (str=0x7b0d68 "\031ަ", flags=0, rlen=0x0) at 
strtrans.c:282
282   *r++ = c;
(gdb) bt
#0  0x004b4bc0 in ansic_quote (str=0x7b0d68 "\031ަ", flags=0, rlen=0x0) 
at strtrans.c:282
#1  0x004a4121 in printf_builtin (list=0x7b0da8) at ./printf.def:567
#2  0x00440e37 in execute_builtin (builtin=0x4a2e64 , 
words=0x7b0d48, flags=0, subshell=0)
at execute_cmd.c:4337
#3  0x00441a4a in execute_builtin_or_function (words=0x7b0d48, 
builtin=0x4a2e64 , var=0x0, redirects=0x0, 
fds_to_close=0x7b08a8, flags=0) at execute_cmd.c:4758
#4  0x004408e8 in execute_simple_command (simple_command=0x7b0648, 
pipe_in=-1, pipe_out=-1, async=0, fds_to_close=0x7b08a8)
at execute_cmd.c:4161
#5  0x0043a796 in execute_command_internal (command=0x7b06c8, 
asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x7b08a8)
at execute_cmd.c:787
#6  0x00439d44 in execute_command (command=0x7b06c8) at 
execute_cmd.c:390
#7  0x004255e1 in reader_loop () at eval.c:160
#8  0x00423431 in main (argc=2, argv=0x7fffeab8, 
env=0x7fffead0) at shell.c:755
(gdb) info locals
r = 0x7b2000 
ret = 0x7b0de8 
"$'\\031\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336\336",
 ...
s = 0x7b0d69 "ަ"
l = 0
rsize = 16
c = 222 '\336'
clen = 2
b = 0
wc = 1958 L'ަ'
(gdb) quit
A debugging session is active.

Inferior 1 [process 28162] will be killed.

Quit anyway? (y or n) y
dualbus@debian:~$ cat invalid-utf8
LC_CTYPE=en_US.UTF-8
printf '%q\n' $'\031\336\246'
dualbus@debian:~$ bash invalid-utf8 
Segmentation fault
dualbus@debian:~$ bash --version
GNU bash, version 4.3.0(1)-rc2 (x86_64-unknown-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
dualbus@debian:~$ cat invalid-utf8-c-locale 
LC_CTYPE=C
printf '%q\n' $'\031\336\246'
dualbus@debian:~$ bash invalid-utf8-c-locale 
$'\031\336\246'
dualbus@debian:~$ logout



The commit that introduced the bug is the following:

$ git log -n1 --pretty=medium c920c360
commit c920c360da817d2ee755e8ed94ae7d5b9ce313db
Author: Chet Ramey 
Date:   Mon Jan 9 08:27:00 2012 -0500

commit bash-20110902 snapshot

-- 
Eduardo Alan Bustamante López

Re: Invalid byte sequence under UTF-8 locale generates a segmentation fault when using printf %q (ansic_quote)

[Chet Ramey]

On 2/13/14 11:33 AM, Eduardo A. Bustamante López wrote:
> Using an invalid byte sequence with printf %q segfaults bash, for a
> UTF-8 locale.

http://lists.gnu.org/archive/html/bug-bash/2014-02/msg00033.html


-- 
``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: Please accept M-p as well as C-p

[Chet Ramey]

On 2/13/14 11:29 AM, Andreas Schwab wrote:

> AIUI there is no readline command the moves
> vertically within the commandline (in readline a line always includes
> any embedded newlines).

That's true.  How should such a command work?  Move point forward and
backward by a multiple of the screenwidth?

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: Please accept M-p as well as C-p

[Andreas Schwab]

Chet Ramey  writes:

> On 2/13/14 11:29 AM, Andreas Schwab wrote:
>
>> AIUI there is no readline command the moves
>> vertically within the commandline (in readline a line always includes
>> any embedded newlines).
>
> That's true.  How should such a command work?  Move point forward and
> backward by a multiple of the screenwidth?

It should work like previous-line/next-line in Emacs: move over the
previous/next newline and then forward to the same column as before.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Invalid byte sequence under UTF-8 locale generates a segmentation fault when using printf %q (ansic_quote)

[Eduardo A . Bustamante López]

On Thu, Feb 13, 2014 at 11:37:27AM -0500, Chet Ramey wrote:
> On 2/13/14 11:33 AM, Eduardo A. Bustamante López wrote:
> > Using an invalid byte sequence with printf %q segfaults bash, for a
> > UTF-8 locale.
> 
> http://lists.gnu.org/archive/html/bug-bash/2014-02/msg00033.html
Thanks! I remember that issue, but didn't cross my mind that they
might be related. That patch fixes this issue.

-- 
Eduardo Alan Bustamante López

Re: Invalid byte sequence under UTF-8 locale generates a segmentation fault when using printf %q (ansic_quote)

[Eduardo A . Bustamante López]

On Thu, Feb 13, 2014 at 11:37:27AM -0500, Chet Ramey wrote:
> On 2/13/14 11:33 AM, Eduardo A. Bustamante López wrote:
> > Using an invalid byte sequence with printf %q segfaults bash, for a
> > UTF-8 locale.
> 
> http://lists.gnu.org/archive/html/bug-bash/2014-02/msg00033.html
> 
Uhm, apparently the patch doesn't fix the issue entirely. It did fix
the issue for the original payload, but I tested with new payloads,
and it still fails. Found three ways to trigger it:


dualbus@debian:~/nbug$ ls
command-name  invalid-bytes  payloads  printf-q  quote.patch  set-x
dualbus@debian:~/nbug$ cat command-name 
payload=$'\065\247\100\063\231\053\306\123\070\237\242\352\263'
"$payload"
dualbus@debian:~/nbug$ cat printf-q 
payload=$'\065\247\100\063\231\053\306\123\070\237\242\352\263'
printf %q "$payload"
dualbus@debian:~/nbug$ cat set-x 
payload=$'\065\247\100\063\231\053\306\123\070\237\242\352\263'
(set -x; : "$payload")
dualbus@debian:~/nbug$ gdb ~/local/bin/bash
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/dualbus/local/bin/bash...done.
(gdb) r ./printf-q
Starting program: /home/dualbus/local/bin/bash ./printf-q

Program received signal SIGSEGV, Segmentation fault.
0x004b4ba6 in ansic_quote (str=0x7b0ec8 '3' ..., 
flags=0, rlen=0x0) at strtrans.c:279
279 *r++ = c;
(gdb) bt
#0  0x004b4ba6 in ansic_quote (str=0x7b0ec8 '3' ..., 
flags=0, rlen=0x0) at strtrans.c:279
#1  0x004a4121 in printf_builtin (list=0x7b0dc8) at ./printf.def:567
#2  0x00440e37 in execute_builtin (builtin=0x4a2e64 , 
words=0x7b0d88, flags=0, subshell=0)
at execute_cmd.c:4337
#3  0x00441a4a in execute_builtin_or_function (words=0x7b0d88, 
builtin=0x4a2e64 , var=0x0, redirects=0x0, 
fds_to_close=0x7b0ba8, flags=0) at execute_cmd.c:4758
#4  0x004408e8 in execute_simple_command (simple_command=0x7b0708, 
pipe_in=-1, pipe_out=-1, async=0, fds_to_close=0x7b0ba8)
at execute_cmd.c:4161
#5  0x0043a796 in execute_command_internal (command=0x7b0788, 
asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x7b0ba8)
at execute_cmd.c:787
#6  0x00439d44 in execute_command (command=0x7b0788) at 
execute_cmd.c:390
#7  0x004255e1 in reader_loop () at eval.c:160
#8  0x00423431 in main (argc=2, argv=0x7fffeab8, 
env=0x7fffead0) at shell.c:755
(gdb) list
274 }
275   if (l)
276 *r++ = '\\';
277 
278   if (clen == 1)
279 *r++ = c;
280   else
281 {
282   for (b = 0; b < (int)clen; b++)
283 *r++ = (unsigned char)s[b];
(gdb) 
284   s += clen - 1;/* -1 because of the increment above */
285 }
286 }
287 
288   *r++ = '\'';
289   *r = '\0';
290   if (rlen)
291 *rlen = r - ret;
292   return ret;
293 }
(gdb) info locals
r = 0x7b2000 
ret = 0x7b0e48 "$'5\\247@", '3' ...
s = 0x7b1fff "3" 
l = 0
rsize = 56
c = 51 '3'
clen = 1
b = 1
wc = 64 L'@'
(gdb) quit
A debugging session is active.

Inferior 1 [process 2017] will be killed.

Quit anyway? (y or n) y
dualbus@debian:~/nbug$ 


As you can see from the gdb list command, the patch has been applied,
and it still shows the issue. If you are interested, I have a list of
payloads that trigger the bug differently for each of the three
tests (some segfault, some not).

You have to ''set follow-fork-mode child'' for the command-name
example to trace it in gdb.

-- 
Eduardo Alan Bustamante López

Re: Invalid byte sequence under UTF-8 locale generates a segmentation fault when using printf %q (ansic_quote)

[Chet Ramey]

On 2/13/14 2:32 PM, Eduardo A. Bustamante López wrote:
> On Thu, Feb 13, 2014 at 11:37:27AM -0500, Chet Ramey wrote:
>> On 2/13/14 11:33 AM, Eduardo A. Bustamante López wrote:
>>> Using an invalid byte sequence with printf %q segfaults bash, for a
>>> UTF-8 locale.

I think it depends on your system and locale.  I only had the third
example produce a seg fault, but it was enough.  Try the attached
updated patch.

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/
*** ../bash-4.3-rc2/lib/sh/strtrans.c	2013-03-09 14:55:18.0 -0500
--- lib/sh/strtrans.c	2014-02-13 15:23:29.0 -0500
***
*** 258,262 
  	  b = is_basic (c);
  	  /* XXX - clen comparison to 0 is dicey */
! 	  if ((b == 0 && ((clen = mbrtowc (&wc, s, MB_CUR_MAX, 0)) < 0 || iswprint (wc) == 0)) ||
  	  (b == 1 && ISPRINT (c) == 0))
  #else
--- 258,262 
  	  b = is_basic (c);
  	  /* XXX - clen comparison to 0 is dicey */
! 	  if ((b == 0 && ((clen = mbrtowc (&wc, s, MB_CUR_MAX, 0)) < 0 || MB_INVALIDCH (clen) || iswprint (wc) == 0)) ||
  	  (b == 1 && ISPRINT (c) == 0))
  #else
***
*** 279,284 
  	*r++ = c;
else
! 	for (b = 0; b < (int)clen; c = b ? *++s : c)
! 	  *r++ = c;
  }
  
--- 279,287 
  	*r++ = c;
else
! 	{
! 	  for (b = 0; b < (int)clen; b++)
! 	*r++ = (unsigned char)s[b];
! 	  s += clen - 1;	/* -1 because of the increment above */
! 	}
  }
  

Re: Browsing the history of commands. Inconsistency between Bash and Emacs

[Bob Proulx]

Dani Moncayo wrote:
> Emacs uses M-p/M-n to browse the minibuffer history (and C-p/C-n to
> move to the previous/next line in a multi-line buffer), whereas Bash
> uses C-n/C-p for browsing the command history (and doesn't use M-p/M-n
> for anything, AFAIK).
> 
> It would be nice to remove this inconsistency (this is the obvious
> part), and IMO TRT would be to make Bash behave like Emacs, that is:
> 1. Use M-p/M-n to browse the command history (instead of the current C-p/C-n).
> 2. Use C-p/C-n to move to the previous/next line, in the current
> command being edited.
> 
> WDYT?

This is completely putting the cart before the horse.  And going down
that road creates a circular line of reasoning which has no end to the
loop cycle.  Plus it is a radical change in fundamental behavior.
Please don't.

The entire reason that bash's readline emacs mode uses C-n and C-p is
that those are the emacs keys for next-line and previous-line.  If
emacs were using M-p and M-n for previous and next then bash would
have done so too.  Bash didn't make this up.  It is using the keys
from emacs for emacs mode and those keys are C-n and C-p.  Editing the
history is just like editing a file.  C-p takes you to the previous
line.  C-n takes you to the next line.

Now enter emacs.  I mean literally.  (I have been using emacs for a
very long time by the way.  I am using it now.)  Emacs has the feature
including of being able to edit the minibuffer and also being able to
run an inferior shell process in a buffer.  Both are very similar
cases and should be discussed together.  In those buffers if you want
to go to the previous line or the next line then what keys do you use?
You use C-p and C-n to go to the previous line or the next line.

But that is not editing the history.  That is editing the buffer.
There the previous and next lines are parts of the visible screen.  It
isn't a history of the screen.  For using bash in an inferior shell if
you want to recall shell history you can't use C-p and C-n because
those are shadowed by the emacs layer of keybindings that move
previous and next lines.  Therefore M-p and M-n were the natural
second choice to navigate by adding another mental layer of
navigation.  (Although emacs itself is keeping the input history.)
Same thing for the minibuffer.

So now people say, I am now used to using M-p and M-n in emacs to
avoid the C-p/C-n.  Let's set that up for bash.  (Of course you can
easily do this if you desire.  Just do it.  Several people suggested
it.)  Well, let's say for discussion that you get used to that
setting.  The entire argument so far is that people are "used to it".

Now people become used to navigating the previous line with M-p and
the next line with M-n in bash.  Now they go to emacs.  What do they
do there?  They find that in emacs M-p and M-n *do not navigate* the
previous line and next line.  They find that bash and emacs are once
again inconsistent!

In that future time let me file a bug with emacs asking for them to
change their previous-line and next-line key bindings to be compatible
with the new bash bindings of M-p and M-n for previous and next line.
Why?  Because they are "used to it".  That request is just as valid as
this request to do so with bash.  So why not?  Why wouldn't emacs
change M-p and M-n to be previous line and next line?  Let's say they
do for continued discussion.

Now in the future, future time where emacs has now adopted M-p and M-n
for previous and next line.  Now they need a way to escape the emacs
layer again but with the new set of keys.  In emacs I really don't
want to need to use C-c as a prefix key for the minibuffer and the
inferior shell buffer like in term mode.  But let's say they do.
Would there then be a request for bash to set up C-c M-n and C-c M-p
for next and previous line?  I think there would be and it would just
be an endless cycle.

As Chet said the mental model of what is happening at those two points
of action in each program is different.

Bob

P.S. This is going to be a rant and run because I am offline for
several days after this.

Re: Please accept M-p as well as C-p

[Bob Proulx]

Andreas Schwab wrote:
> Chet Ramey writes:
> > Andreas Schwab wrote:
> >> AIUI there is no readline command the moves
> >> vertically within the commandline (in readline a line always includes
> >> any embedded newlines).
> >
> > That's true.  How should such a command work?  Move point forward and
> > backward by a multiple of the screenwidth?
> 
> It should work like previous-line/next-line in Emacs: move over the
> previous/next newline and then forward to the same column as before.

In emacs 24 this is the new feature controlled by the line-move-visual
variable.  Call me a Luddite if you want but in emacs 24 I turn that
feature off.  I am very much "used to using" the traditional behavior
and like it.

Thinking about it I think that the recent addition of line-move-visual
to emacs and not to libreadline is probably the reason for the request
for this feature.

Bob

Re: Invalid byte sequence under UTF-8 locale generates a segmentation fault when using printf %q (ansic_quote)

[Eduardo A . Bustamante López]

On Thu, Feb 13, 2014 at 04:01:21PM -0500, Chet Ramey wrote:
> On 2/13/14 2:32 PM, Eduardo A. Bustamante López wrote:
> > On Thu, Feb 13, 2014 at 11:37:27AM -0500, Chet Ramey wrote:
> >> On 2/13/14 11:33 AM, Eduardo A. Bustamante López wrote:
> >>> Using an invalid byte sequence with printf %q segfaults bash, for a
> >>> UTF-8 locale.
> 
> I think it depends on your system and locale.  I only had the third
> example produce a seg fault, but it was enough.  Try the attached
> updated patch.
Perfect. This new patch passes all the tests I setup. I confirm that
it works.

Thanks!

-- 
Eduardo Alan Bustamante López

Re: Browsing the history of commands. Inconsistency between Bash and Emacs

[Chet Ramey]

On 2/13/14, 9:40 AM, Dani Moncayo wrote:
> Hello, Bash developers,
> 
> (I know little about Bash, so I apologize beforehand if I say
> something inaccurate or nonsensical)
> 
> Bug #16740 was filed today against the Emacs package, asking to remove
> an inconsistency between the keys employed by Emacs and Bash to browse
> the history of commands.  See:
> 
>   http://lists.gnu.org/archive/html/bug-gnu-emacs/2014-02/msg01082.html
> 
> Emacs uses M-p/M-n to browse the minibuffer history (and C-p/C-n to
> move to the previous/next line in a multi-line buffer), whereas Bash
> uses C-n/C-p for browsing the command history (and doesn't use M-p/M-n
> for anything, AFAIK).

I said in an earlier message that the two programs use different mental
models.  Here's what I meant.

Readline is one-dimensional: everything it deals with is a line.  Emacs
is two-dimensional: there is a (logical) array of lines presented a
screenful at a time.  Emacs uses C-p and C-n to move between lines; even
when in a shell minibuffer, C-p and C-n can be used to move around
previous command output.  Since readline is one-dimensional, the way you
add a second dimension is through the history.  It doesn't, and can't,
know anything about the rest of the screen's contents.  It's only concerned
with the current line.  Readline uses C-p and C-n to move up and down
through its units of lines: the history.  This is consistent.

Emacs needed a different set of key bindings to move through the history,
and it chose M-p and M-n.  Users who want that kind of consistency can
easily bind M-p and M-n to previous-history and next-history, respectively.

> It would be nice to remove this inconsistency (this is the obvious
> part), and IMO TRT would be to make Bash behave like Emacs, that is:
> 1. Use M-p/M-n to browse the command history (instead of the current C-p/C-n).
> 2. Use C-p/C-n to move to the previous/next line, in the current
> command being edited.

No.  The use of C-p and C-n for this is pervasive and long-lived.  There is
no reason to break 25 years of backwards compatibility and compatibility
with other shells to make this change.

I'm not opposed to looking at a readline command to move through physical
lines of a line containing embedded newlines (rare) or a line exceeding the
screen width that ends up getting wrapped (common), as long as such a
command can be specified and implemented.

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/