Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ctrl-w should delete a word instead of a whole line #3

Closed
maddyblue opened this issue Oct 26, 2017 · 8 comments
Closed

ctrl-w should delete a word instead of a whole line #3

maddyblue opened this issue Oct 26, 2017 · 8 comments

Comments

@maddyblue
Copy link

Pressing ctrl-w deletes a line (which I expect from ctrl-u) instead of a word. Is this intended? If not can it be changed to be a word only? It makes fixing a bad word much more annoying, as I usually delete the entire line due to muscle memory.

@benesch
Copy link
Collaborator

benesch commented Nov 30, 2017

This appears to be a difference between editline and readline.

Editline:

Ctrl-W em-kill-region
em-kill-region (emacs: Ctrl-W)
Delete the string from the cursor to the mark and save it to the
cut buffer. It is an error if the mark is not set.

https://www.daemon-systems.org/man/editline.7.html

Readline:

unix-word-rubout (C-w)
Kill the word behind point, using white space as a word boundary. The killed text is saved on the kill-ring.

https://www.gnu.org/software/bash/manual/html_node/Commands-For-Killing.html#Commands-For-Killing

You should be able to fix it for not just Cockroach but all editline based programs with a config like

# ~/.editrc
bind "^W" ed-delete-prev-word

@maddyblue
Copy link
Author

This doesn't appear to work. I made that my ~/.editrc and ctrl-w still deletes the whole line.

@benesch
Copy link
Collaborator

benesch commented Apr 12, 2018

It definitely works for me. Dumb question: you restarted the Cockroach shell after changing editrc, right?

@maddyblue
Copy link
Author

Yup. And tried putting .editrc in the same directory as the binary. Dunno.

@benesch
Copy link
Collaborator

benesch commented Apr 12, 2018

Happy to take a look with you if you'd like. Somehow I feel like it's related to your Linux setup. The next step is to put a bare bind command in your editrc. If your editrc is actually being parsed, you'll see output like this before every prompt:

# You are connected to a temporary, in-memory CockroachDB instance. Your changes
# will not be saved.
#
Standard key bindings
"^@"           ->  em-set-mark
"^A"           ->  ed-move-to-beg
"^B"           ->  ed-prev-char
"^C"           ->  rl_interrupt
"^D"           ->  em-delete-or-list
"^E"           ->  ed-move-to-end
...
root@127.0.0.1:49636/demo> 

If you don't see anything like that, strace'ing the shell would be illustrative.

benesch added a commit that referenced this issue Apr 13, 2018
In order to source ~/.editrc, libedit looks up the value of the HOME
environment variable using secure_getenv. Previously, because
HAVE_SECURE_GETENV was not defined when compiling libedit on Linux,
libedit would be unable to lookup HOME and give up on sourcing
~/.editrc.

Defining HAVE_SECURE_GETENV fixes the problem, but only with glibc.
Musl does not provide a secure_getenv function. Work around that by
providing a shim implementation of secure_getenv for musl that uses the
issetugid function instead.

Compilation against a non-glibc library that does not provide issetugid
will fail. I don't think it's possible to fix this (i.e., compiling but
refusing to lookup HOME at runtime) while continuing to compile libedit
with cgo, though.

Fix #3.
benesch added a commit that referenced this issue Apr 14, 2018
In order to source ~/.editrc, libedit looks up the value of the HOME
environment variable using secure_getenv. Previously, because
HAVE_SECURE_GETENV was not defined when compiling libedit on Linux,
libedit would be unable to lookup HOME and give up on sourcing
~/.editrc.

Defining HAVE_SECURE_GETENV fixes the problem, but only with glibc.
Musl does not provide a secure_getenv function. Work around that by
providing a shim implementation of secure_getenv for musl that uses the
issetugid function instead.

Compilation against a non-glibc library that does not provide issetugid
will fail. I don't think it's possible to fix this (i.e., compiling but
refusing to lookup HOME at runtime) while continuing to compile libedit
with cgo, though.

Fix #3.
@knz
Copy link
Owner

knz commented Aug 2, 2018

@benesch I have tried your .editrc thing above and it works for me too. Can you explain to me why making this work for Matt requires implementing secure_getenv?

@knz
Copy link
Owner

knz commented Aug 3, 2018

The .editrc recommendation above should now work properly on linux.

@maddyblue
Copy link
Author

This works now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants