Re: ctrl-w oddity on bash-4.4

[Chet Ramey]

On 10/22/17 6:52 PM, Aron Griffis wrote:
> I'm seeing some strange behavior and don't know if it's a bug or intended.
> 
> Reproducer:
> 1. env INPUTRC=/dev/null bash --norc
> 2. set -o vi
> 3. true --foo=bar
> 4. up arrow, then left arrow to put the cursor on the equals sign
> 5. press ctrl-w, nothing happens

Posix says the word boundaries for ^W in insert mode are characters that
aren't  or . So you deal with the character before the
cursor (`o'), and delete to a character that isn't  or .
Since the `o' is in neither character class, it's the word boundary, and
you don't delete anything. FWIW, ksh93 behaves the same way (but beeps
annoyingly).

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: ctrl-w oddity on bash-4.4

[Eduardo A . Bustamante López]

On Wed, Oct 25, 2017 at 09:48:14AM -0400, Chet Ramey wrote:
> On 10/22/17 6:52 PM, Aron Griffis wrote:
> > I'm seeing some strange behavior and don't know if it's a bug or intended.
> > 
> > Reproducer:
> > 1. env INPUTRC=/dev/null bash --norc
> > 2. set -o vi
> > 3. true --foo=bar
> > 4. up arrow, then left arrow to put the cursor on the equals sign
> > 5. press ctrl-w, nothing happens
> 
> Posix says the word boundaries for ^W in insert mode are characters that
> aren't  or . So you deal with the character before the
> cursor (`o'), and delete to a character that isn't  or .
> Since the `o' is in neither character class, it's the word boundary, and
> you don't delete anything. FWIW, ksh93 behaves the same way (but beeps
> annoyingly).
[...]

Wow. I had to read the POSIX description of ^W a few times to finally
understand how this works. Thank you for the explanation Chet!



Patch for compatibility with ksh93 (just kidding!):

diff --git a/lib/readline/vi_mode.c b/lib/readline/vi_mode.c
index 3cb7e8c9..210d1b12 100644
--- a/lib/readline/vi_mode.c
+++ b/lib/readline/vi_mode.c
@@ -1615,7 +1615,14 @@ rl_vi_unix_word_rubout (int count, int key)
  rl_point--;
}
 
-  rl_kill_text (orig_point, rl_point);
+  if (orig_point == rl_point)
+{
+  rl_ding();
+}
+  else
+{
+  rl_kill_text (orig_point, rl_point);
+}
 }
 
   return 0;

Re: ctrl-w oddity on bash-4.4

[Aron Griffis]

On Wed, Oct 25, 2017 at 9:48 AM, Chet Ramey  wrote:

> On 10/22/17 6:52 PM, Aron Griffis wrote:
> > I'm seeing some strange behavior and don't know if it's a bug or
> intended.
> >
> > Reproducer:
> > 1. env INPUTRC=/dev/null bash --norc
> > 2. set -o vi
> > 3. true --foo=bar
> > 4. up arrow, then left arrow to put the cursor on the equals sign
> > 5. press ctrl-w, nothing happens
>
> Posix says the word boundaries for ^W in insert mode are characters that
> aren't  or . So you deal with the character before the
> cursor (`o'), and delete to a character that isn't  or .
> Since the `o' is in neither character class, it's the word boundary, and
> you don't delete anything. FWIW, ksh93 behaves the same way (but beeps
> annoyingly).
>

Thanks Chet. Seems hard to imagine this is what a user would expect, but
who am I to argue with POSIX? :-)

For myself, the behavior I want is provided by the combination of
bind-tty-special-chars and unix-word-rubout:

set editing-mode vi
# Disabling bind-tty-special-chars allows unix-word-rubout to work:
# http://lists.gnu.org/archive/html/help-bash/2016-11/msg4.html
set bind-tty-special-chars off
set keymap vi-insert
control-w: unix-word-rubout

Thanks,
Aron

Re: ctrl-w oddity on bash-4.4

[Chet Ramey]

On 10/25/17 10:37 AM, Aron Griffis wrote:
> 
> 
> On Wed, Oct 25, 2017 at 9:48 AM, Chet Ramey  > wrote:
> 
> On 10/22/17 6:52 PM, Aron Griffis wrote:
> > I'm seeing some strange behavior and don't know if it's a bug or 
> intended.
> >
> > Reproducer:
> > 1. env INPUTRC=/dev/null bash --norc
> > 2. set -o vi
> > 3. true --foo=bar
> > 4. up arrow, then left arrow to put the cursor on the equals sign
> > 5. press ctrl-w, nothing happens
> 
> Posix says the word boundaries for ^W in insert mode are characters that
> aren't  or . So you deal with the character before the
> cursor (`o'), and delete to a character that isn't  or .
> Since the `o' is in neither character class, it's the word boundary, and
> you don't delete anything. FWIW, ksh93 behaves the same way (but beeps
> annoyingly).
> 
> 
> Thanks Chet. Seems hard to imagine this is what a user would expect, but
> who am I to argue with POSIX? :-)

If you read the discussion in the thread I pointed to last night, `real'
vi supposedly does this kind of thing. I'm not enough of a vi user to
say one way or the other.

> 
> For myself, the behavior I want is provided by the combination of
> bind-tty-special-chars and unix-word-rubout:

Yes, that's the way to get the previous behavior.  There's a little bit
more of an explanation in the posting you referenced.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: ctrl-w oddity on bash-4.4

[Robert Elz]

Date:Wed, 25 Oct 2017 10:45:11 -0400
From:Chet Ramey 
Message-ID:  <6751ad10-cccb-0467-a751-c5be8e745...@case.edu>

  | If you read the discussion in the thread I pointed to last night, `real'
  | vi supposedly does this kind of thing. I'm not enough of a vi user to
  | say one way or the other.

In real vi, ^W (word kill) only works at all on text you have currently
typed in insert mode, there is no concept of moving somewhere, entering
insert mode, and then using ^W to delete backwards, that would be a
totally foreign concept to a vi user.

In command mode (in vi's new enough to support it) ^W relates to window
switching, and isn't related to line editing at all.

So, whatever is happening here, and why, no appeal to what real vi does
can possibly help.

In real vi, the way to delete backwards for text that previously existed,
and you have just moved to, would be to use the 'd' command in command
mode, and give it an address that expresses where you want to delete to.

For what was indicated here, the command would probably be "db".
That issued while sitting on the '=' in "true --foo=bar" deletes "foo".
That seems to work for me in bash-4,4 as well, and is the "correct vi"
method to use (not some "pretend to be like emacs" operator.)

kre

Simple sleep scripts causes SEGFAULT

[Alex Coffin]

I couldn't get bashbug to send this, so I manually am emailing it.
"/usr/bin/bashbug: rmail: not found"
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux minmus 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19
17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.3
Patch Level: 48
Release Status: release

Description:
Segmentation fault. I'm honestly not sure why. I was using batsh to
make a simple script. When I ran it generated a segfault. The segmentation
fault DOES NOT occur if "sleep" is replaced with "echo".
I also ran it on "GNU bash, version 4.4.12(1)-release
(x86_64-redhat-linux-gnu)" using codingground (
https://www.tutorialspoint.com/execute_bash_online.php) the same issue
occurred.

Repeat-By:
Run the following script (assuming you trust me lol):
function sleep {
  local dur
  dur="$1"
  # if replaced with "echo" no segfault.
  sleep ${dur}s
}
"sleep" $((5))

Re: Simple sleep scripts causes SEGFAULT

[Eduardo Bustamante]

On Wed, Oct 25, 2017 at 11:21 PM, Alex Coffin  wrote:
[...]
> Description:
> Segmentation fault. I'm honestly not sure why. I was using batsh to
> make a simple script. When I ran it generated a segfault. The segmentation
> fault DOES NOT occur if "sleep" is replaced with "echo".
> I also ran it on "GNU bash, version 4.4.12(1)-release
> (x86_64-redhat-linux-gnu)" using codingground (
> https://www.tutorialspoint.com/execute_bash_online.php) the same issue
> occurred.
>
> Repeat-By:
> Run the following script (assuming you trust me lol):
> function sleep {
>   local dur
>   dur="$1"
>   # if replaced with "echo" no segfault.
>   sleep ${dur}s
> }
> "sleep" $((5))

You are running the `sleep` function recursively, therefore exhausting
the stack of the bash process. I believe you intended to do something
like this instead:

sleep() {
  command sleep "$.."
}

Re: Simple sleep scripts causes SEGFAULT

[Robert Elz]

Date:Wed, 25 Oct 2017 21:21:23 -0700
From:Alex Coffin 
Message-ID:  


  | Run the following script (assuming you trust me lol):
  | function sleep {
  |   local dur
  |   dur="$1"
  |   # if replaced with "echo" no segfault.
  |   sleep ${dur}s
  | }
  | "sleep" $((5))

This one is easy, your function is calling itself recursively, (sleep,
calls sleep, calls sleep, calls sleep ) until the stack runs out.

When you make the (internal) sleep be echo, the problem vanishes...

You can fix it by renaming the function to be something other than sleep,
by replacing the inner sleep with "command sleep" so it won't run the
function, or by replacing it with /bin/sleep (or wherever sleep is found
on your system.)

kre