Bug in German translation
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux hobbes 2.6.32-24-generic #42-Ubuntu SMP Fri Aug 20 14:24:04 UTC 2010 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 4.1 Patch Level: 5 Release Status: release Description: The German translation for "no such job" is wrong. Reported in Ubuntu here: https://launchpad.net/bugs/630772 Repeat-By: Run "fg" in a German locale: "LANG=de fg" Fix: diff -u -r bash-4.1/po/de.po bash-4.1-translation-fixed/po/de.po --- bash-4.1/po/de.po 2009-12-30 14:25:15.0 +0100 +++ bash-4.1-translation-fixed/po/de.po 2010-09-07 12:05:26.0 +0200 @@ -7,8 +7,8 @@ "Project-Id-Version: bash 4.0\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2009-12-30 08:25-0500\n" -"PO-Revision-Date: 2009-09-14 20:37+0200\n" -"Last-Translator: Nils Naumann \n" +"PO-Revision-Date: 2010-09-07 12:03+0100\n" +"Last-Translator: Henning Eggers \n" "Language-Team: German \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -239,7 +239,7 @@ #: builtins/common.c:282 #, c-format msgid "%s: no such job" -msgstr "%s: Kein solche Job." +msgstr "%s: Kein solcher Job." #: builtins/common.c:290 #, c-format
readline: How to unbind _all_ keys
I don't like to have dozens of key bindings I never use. Currently I am issuing lots of lots of bind -r/-u commands to get rid of the default bindings. This slows down console startup unnecessarily. I would really like to have an inputrc command like $removeall or something like bind -r/-u all. Or is there something undocumented for this purpose? And yes, I know, it's soo dangerous. Henning
Re: readline: How to unbind _all_ keys
On 20/05/2019 07:41, G. Branden Robinson wrote:
Remember that "self-insert" is a binding.
I know (I've been using for over 20 years (v2.01) now)
If you removed all bindings, no keystrokes would do _anything_.
that's exactly what I want in order to then only bind the keys I want
to have bound, like e.g. accept-line etc.
I don't want to have 3 bindings for abort, {backward,forward}-char,
BOL, EOL, {next,previous}-history and so on.
I don't like bindings with \C-x, \e\C.
Of course slf-insert bindings are ok.
But I never use backward-{kill-{line,word},word}, beginning-of-history,
bracketed-paste-begin, complete-*, and many, many more.
Should I one day decide to use such a function, I will bind a key and
then I will use it.
And, should I one day decide to use a terminal emulation that emits
different key-sequences (arrow pad, edit pad and the like), I will
change the relevant bindings. So I don't need bindings for each and
anything.
And here comes another problem: I can remove superfluous bindings like
\C-a, \C-e. But I can not remove bindings with key-sequences my termi-
nal does not produce like \eO[ABCDFH].
Sorry for not sufficiently explaining my intentions in my original
mail, and thanks for your prompt reply.
Henning
Re: readline: How to unbind _all_ keys
On 20/05/2019 15:38, Chet Ramey wrote:
On 5/19/19 10:43 AM, Henning wrote:
I don't like to have dozens of key bindings I never use. Currently I
am issuing lots of lots of bind -r/-u commands to get rid of the
default bindings. This slows down console startup unnecessarily.
I would really like to have an inputrc command like $removeall or
something like bind -r/-u all.
Or is there something undocumented for this purpose?
There is not, and I don't see much point to adding one. If you want to
remove the bindings for all keys, something like this should work:
Sorry, the subject of my mail should have been "... all non-self-insert
kes.
for ((f=0; f < 256; f++ ))
do
bind -r \\$(printf "%03o" $f)
done
smiling ...
The following variant does what I want:
K=( ' ' ! '\"' \# $ % \& \' \( \) \* + , - . /
0 1 2 3 4 5 6 7 8 9 : \; \< = \> \?
@ A B C D E F G H I J K L M N O
P Q R S T U V W X Y Z \[ '\\' \] ^ _
\` a b c d e f g h i j k l m n o
p q r s t u v w x y z \{ \| \} \~ )
for ((k=0; k<95; k++)); do
bind -r "\e${K[k]}"
bind -r "\e\C-${K[k]}"
bind -r "\C-x\C-${K[k]}"
bind -r "\C-x${K[k]}"
bind -r "\C-${K[k]}"
done
for k in O{A,B,C,D,H,F} \\e [200; do
bind -r "\e$k"
done
bind -f /0/e/inputrc
unset k K
But this means nearly 500 bind -r commands. And that was the reason for
my original mail, the question, if there is a less expensive way to get
what I want.
And another problem: after removing all \C-x sequences I used bind -x
to bind a shell command to \C-x proper. The result, when hitting \C-x,
is the following error message:
bash_execute_unix_command: cannot find keymap for command
Using a sequence other than \C-x works as expected.
My guess is that \C-x can't be used alone. And that this can only be
changed in the source code.
Henning
Re: readline: How to unbind _all_ keys
On 21/05/2019 16:16, Chet Ramey wrote: I can't reproduce this using bash-5.0. I took your script, ran it, then bound C-x to execute "echo abc": [snip] And hitting ^X gives me "abc". It doesn't matter whether or not I remove the binding for \C-x itself. I started a console and changed nothing readline/inputrc related and executed your script, but I got the same error message. I'm currently on an uptodate Cygwin system with bash 4.4.12, which is the actual bash version on Cygwin. And an attempt to compile 5.0 failed. A question regarding the error message: "... cannot find keymap for command". What does that mean? Could you give an example that would produce this error message? Thank you. Henning
Re: readline: How to unbind _all_ keys
On 21/05/2019 23:33, Dennis Williamson wrote:
Why don't you unbind the keystrokes that are actually bound?
while read -r b; do bind -r "$b"; done < <(bind -p | awk -F ':' '/./
&& !/self-insert|accept-line|^#/ {gsub("\"", "", $1); print $1}')
That was my first approach when I dealt with this some years ago.
On my system, that takes 0.011 seconds to run and it's not iterating
through a bunch of key sequences that aren't there.
It does seem to leave behind a few, some of which match cchars (control
Here too. So I tried other methods.
As an alternative, just put all the (un)bindings in ~/.inputrc, for example:
"\C-s": ""
To automate that:
bind -p | awk -F ':' '/./ && !/self-insert|accept-line|^#/ {print $1 ":
\"\""}' >> ~/.inputrc
I tried that, too. But this also left some bindings behind.
Frankly, I'd have to dislike key bindings A LOT to go to the trouble of
doing all this unbinding.
Yes. And I need several combinations for other purposes.
But I can not remove bindings with key-sequences my terminal does not
produce like \eO[ABCDFH]
That seems to be wrong. Currently, the script works perfectly and the
time is acceptable.
What still remains is the not working assignment of ^X.
This inquiry would have been better suited for help-bash rather than
bug-bash.
Hmm. Yes (except for ^X)
Henning
Re: readline: How to unbind _all_ keys
On 22/05/2019 14:58, Koichi Murase wrote: What still remains is the not working assignment of ^X. Henning Hi, I guess you are using Bash 4.4 because, according to my records, bind -x '"\C-x": ...' after unbinding all the keyseqs causes segfaults in Bash-3.0, 3.1 and 4.0--4.2, infinite loops in Bash 3.2, and error messages like "bash_execute_unix_command: ..." in Bash 4.4. It just works with Bash 4.3 and 5.0+. good info. Thanks a lot. b. If you want to support older Bash, the second easiest way is to use on this machine I'm in the Cygwin world. And here 4.4.12 is the actual version. I'll try compiling 5.0 again, else wait for the cygwin guys to offi- cially announce 5.0 Henning
Re: bug-report: debug trap messes up pipestatus if containing command substitution
On 22/05/2019 16:27, Chet Ramey wrote:
On 5/21/19 12:51 AM, Hengyang Zhao wrote:
Dear bash developers,
I found an unexpected behavior when engineering some code in a callback of
DEBUG trap. The code has been distilled to expose this behavior:
### BEGIN
my_func() {
local x=$(:)
}
trap my_func DEBUG
false | true | false | true | false
echo ${PIPESTATUS[@]}
# expects 1 0 1 0 1
# gets 0 0 0 0 1
### END
Thanks for the report. This appears to be a Linux-only problem (at least I
can't reproduce it on Mac OS X). I'll fix it for the next devel push.
Chet
Same with bash 4.4.12 on Cygwin
Henning
Re: readline: How to unbind _all_ keys
igncr. As a result, we want to ensure SHELLOPTS parsing does not turn
+ on interactive options when exported from an interactive shell, but
+ parse in a non-interactive setting, so as not to break POSIX
/bin/sh */
+ int interactive_only;
+#endif
} o_options[] = {
{ "allexport", 'a', (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL },
#if defined (BRACE_EXPANSION)
{ "braceexpand",'B', (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL },
#endif
#if defined (READLINE)
- { "emacs", '\0', (int *)NULL, set_edit_mode, get_edit_mode },
+ { "emacs", '\0', (int *)NULL, set_edit_mode, get_edit_mode
INTERACTIVE_ONLY },
#endif
{ "errexit", 'e', (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL },
{ "errtrace", 'E', (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL },
{ "functrace", 'T', (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL },
{ "hashall",'h', (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL },
#if defined (BANG_HISTORY)
- { "histexpand", 'H', (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL },
+ { "histexpand", 'H', (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL INTERACTIVE_ONLY },
#endif /* BANG_HISTORY */
#if defined (HISTORY)
- { "history", '\0', &enable_history_list, bash_set_history,
(setopt_get_func_t *)NULL },
+ { "history", '\0', &enable_history_list, bash_set_history,
(setopt_get_func_t *)NULL INTERACTIVE_ONLY },
+#endif
+#ifdef __CYGWIN__
+ { "igncr", '\0', &igncr, NULL, (setopt_get_func_t *)NULL },
#endif
{ "ignoreeof", '\0', &ignoreeof, set_ignoreeof, (setopt_get_func_t
*)NULL },
{ "interactive-comments", '\0', &interactive_comments,
(setopt_set_func_t *)NULL, (setopt_get_func_t *)NULL },
{ "keyword",'k', (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL },
#if defined (JOB_CONTROL)
- { "monitor", 'm', (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL },
+ { "monitor", 'm', (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL INTERACTIVE_ONLY },
#endif
{ "noclobber", 'C', (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL },
{ "noexec", 'n', (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL },
@@ -233,7 +253,7 @@ const struct {
{ "privileged", 'p', (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL },
{ "verbose", 'v', (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL },
#if defined (READLINE)
- { "vi",'\0', (int *)NULL, set_edit_mode, get_edit_mode },
+ { "vi",'\0', (int *)NULL, set_edit_mode, get_edit_mode
INTERACTIVE_ONLY },
#endif
{ "xtrace", 'x', (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL },
{(char *)NULL, 0 , (int *)NULL, (setopt_set_func_t *)NULL,
(setopt_get_func_t *)NULL },
@@ -455,6 +475,15 @@ int
set_minus_o_option (on_or_off, option_name)
int on_or_off;
char *option_name;
+#ifdef __CYGWIN__
+{
+ /* See Cygwin comments above. */
+ return set_minus_o_option_maybe (on_or_off, option_name, 0);
+}
+static int
+set_minus_o_option_maybe (int on_or_off, const char *option_name,
+ int avoid_interactive)
+#endif /* __CYGWIN__ */
{
register int i;
@@ -462,6 +491,10 @@ set_minus_o_option (on_or_off, option_na
{
if (STREQ (option_name, o_options[i].name))
{
+#ifdef __CYGWIN__
+ if (o_options[i].interactive_only && avoid_interactive)
+ return EXECUTION_SUCCESS;
+#endif
if (o_options[i].letter == 0)
{
previous_option_value = GET_BINARY_O_OPTION_VALUE (i,
o_options[i].name);
@@ -588,7 +621,11 @@ parse_shellopts (value)
vptr = 0;
while (vname = extract_colon_unit (value, &vptr))
{
+#ifdef __CYGWIN__
+ set_minus_o_option_maybe (FLAG_ON, vname, !interactive_shell);
+#else
set_minus_o_option (FLAG_ON, vname);
+#endif
free (vname);
}
}
--
Several hunks applied, others could be applied manually. But the lines
where INTERACTIVE_ONLY was added, produced an error message like
expected } before INTERACTIVE_ONLY
All this is of course far beyond my knowledge and I wouldn't mind you
asking me to be patient and wait for cygwin ...
Thanks for your efforts
Henning
Re: readline: How to unbind _all_ keys
On 24/05/2019 17:16, Chet Ramey wrote:
That's not in the distributed version of bash-5.0. If you're applying an
older cygwin patch, have you tried just building the distributed version?
Let's make sure that works.
Bang! It does. So sorry that I didn't have that idea myself. Especially
as I have never used the 'igncr' stuff anyway. I hope there won't
appear ther Windows related issues.
I'm going to explore things now. And I have been waiting for
{previous,next}-screen-line and several other things.
Thanks a lot.
Henning
previous/next-screen-line (was: readline: How to unbind _all_ keys)
On 25/05/2019 11:14, Henning wrote:
On 24/05/2019 17:16, Chet Ramey wrote:
That's not in the distributed version of bash-5.0. If you're applying an
older cygwin patch, have you tried just building the distributed version?
Let's make sure that works.
Bang! It does. So sorry that I didn't have that idea myself. Especially
as I have never used the 'igncr' stuff anyway. I hope there won't
appear ther Windows related issues.
I'm going to explore things now. And I have been waiting for
{previous,next}-screen-line and several other things.
These two (*-screen-line) functions, to my disappointment, don't
work as I expected. They simply shift the cursor left/up or
right/down by COLUMNS characters. And that's seldom useful.
I am using multi-line commands to try out things, usually sed scripts;
while, until or for loops or the like. Once I'm satisfied I put things
into a function or script. Lines are seldom longer than 20 or 30
characters.
So I sat down and developed a solution using 'bind -x': The functions
below find the position on the current screen line and then set
READLINE_POINT to the respective position on the previous/next line.
The result is real vertical cursor movement. Exceptions:
1. if prev/next line is shorter than position in current line
the cursor is placed at EOL of prev/next line.
2. if there's no prev/next line the cursor jumps to BOL/EOL and
the terminal bell is rang.
3. if there are special characters like ^[ or ^? inserted literally
with ^Q/^V in the way there may be a 1 character deviation.
Similar with literal TABs.
4. My knowledge about and therefore my desire to deal with UTF8,
Unicode, Multibyte or the like equals zero. So I can't help with that.
#-
PreviousScreenLine() {
local n=$'\n' A B R=$READLINE_LINE
local -i a b r=READLINE_POINT
A=${R:0:r} # BOC -> point
if [[ "$A" != *$n* ]]; then # if there's no previous line
READLINE_POINT=0 #go to BOC
printf \\a #and ring terminal bell
else
B=${A##*$n} b=${#B} # BOL -> point & length
A=${A%$n*} # lines before current
B=${A##*$n} a=${#B} # previous line & length
((a EOC, BOC -> point
if [[ "$A" != *$n* ]]; then # if there's no next line
READLINE_POINT=${#R}#go to EOC
printf \\a #and ring terminal bell
else
B=${B##*$n} b=${#B}# BOL -> point & length
A=${A#*$n} # lines after current
B=${A%%$n*} a=${#B}# next line & length
((a
Re: Unexpected result of array assignment
On 18/07/2019 03:16, Darren 'Tadgy' Austin wrote:
foo=(["key"]="${foo["key"]} value2")
using eval shoud also succeed, even for older bash:
eval 'foo=(["key"]="'"${foo["key"]}"' value2")'
Henning
Re: Unexpected result of array assignment
On 18/07/2019 11:19, Andreas Schwab wrote:
On Jul 18 2019, Henning wrote:
eval 'foo=(["key"]="'"${foo["key"]}"' value2")'
This will break if ${foo["key"]} contains any of $ ` " \ .
Correct. I'd only taken blanks into account.
Henning
Re: Unexpected result of array assignment
On 18/07/2019 14:12, Greg Wooledge wrote:
On Thu, Jul 18, 2019 at 10:58:52AM +0200, Henning wrote:
eval 'foo=(["key"]="'"${foo["key"]}"' value2")'
If you just want to work around the bug, why not do it in the simplest
way possible?
foo["key"]+=" value2"
Of course, you are right.
Henning
Changing window size via bind -x may cause bash to hang in futex() call
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-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=x86-64
-mtune=generic -O2 -pipe
-DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin'
-DSTANDARD_UTILS_PATH='/usr/bin:/bin:/usr/sbin:/sbin'
-DSYS_BASHRC='/etc/bash.bashrc' -DSYS_BASH_LOGOUT='/etc/bash.bash_logout'
uname output: Linux golem 2.6.37-ARCH #1 SMP PREEMPT Fri Feb 18 18:32:16 CET
2011 x86_64 AMD Phenom(tm) II X4 955 Processor AuthenticAMD GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.2
Patch Level: 0
Release Status: release
Description: When the size of an XTerminal is changed via a keybinding
(either by issuing an escape sequence or by an external
program that uses xlib) then sometimes bash will simply hang
before redrawing the prompt, not responding to C-c
anymore. I've used strace to verify that it's not the terminal
but indeed bash that seems to hang, apparently in a
futex(...FUTEX_WAIT...) call.
Repeat-By:
test script (test_resize.bash):
---snip---
dostuff () {
for((i=0; i<1000; i++)) {
echo "$i";
}
}
bind -x '"\ea": echo -ne "\e[8;12;80t"; dostuff'
bind -x '"\es": echo -ne "\e[8;24;80t"; dostuff'
bind -x '"\ew": xdotool windowsize --usehints $WINDOWID 80 12; dostuff'
bind -x '"\eq": xdotool windowsize --usehints $WINDOWID 80 24; dostuff'
toggle_size_fast () {
while :; do
echo -ne "\e[8;12;80t"
echo -ne "\e[8;24;80t"
done
}
---snip---
$ strace -o strace.log bash --rcfile test_resize.bash
When I use either M-a/M-s to toggle the size via escape
sequences or M-q/M-w to toggle using xdotool the freeze will
eventually occur after a few times. The dostuff() part makes
it appear sooner, but it also happens without it (it is harder
to trigger it in that case, though). This happens regardless
of whether checkwinsize is set or not.
When I run toogle_size_fast, I get a lot of interrupted system
call messages, but the resizing happens alright, bash never
hangs and C-c exits the function as usual.
I've tested this in xterm, urxvt and lilyterm (vte-based),
with both bash 4.2.0 and bash 4.1.9.
This is the strace output of a hang triggered by M-q:
read(0, "\33", 1) = 1
read(0, "q", 1) = 1
write(2, "\r\33[K", 4) = 4
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
pipe([3, 4])= 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7fec5c96c9d0) = 1255
setpgid(1255, 1255) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
close(3)= 0
close(4)= 0
ioctl(255, TIOCGPGRP, [1255]) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WSTOPPED|WCONTINUED, NULL) =
1255
rt_sigprocmask(SIG_BLOCK, [CHLD TSTP TTIN TTOU], [CHLD], 8) = 0
ioctl(255, TIOCSPGRP, [1065]) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
ioctl(255, SNDCTL_TMR_TIMEBASE or TCGETS, {B400 opost isig -icanon -echo
...}) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, 0x7fffb9e736dc, WNOHANG|WSTOPPED|WCONTINUED, NULL) = -1 ECHILD (No
child processes)
rt_sigreturn(0x)= 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
--- SIGWINCH (Window changed) @ 0 (0) ---
ioctl(0, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=640, ws_ypixel=336}) = 0
mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1,
0) = 0x7fec537e7000
munmap(0x7fec537e7000, 8491008) = 0
munmap(0x7fec5800, 58617856)= 0
mprotect(0x7fec5400, 135168, PROT_READ|PROT_WRITE) = 0
futex(0x7fec5c0d8ea0, FUTEX_WAIT, 2, NULL) = ? ERESTARTSYS (To be restarted)
--- SIGINT (Interrupt) @ 0 (0) ---
rt_sigreturn(0x2) = -1 EINTR (Interrupted system call)
futex(0x7fec5c0d8ea0, FUTEX_WAIT, 2, NULL
Re: Changing window size via bind -x may cause bash to hang in futex() call
I've noticed that this problem does no longer occur if bash 4.2.8 is configured --with-bash-malloc. On my distribution (arch) bash is configured --without-bash-malloc by default. This is the configuration i use now (derived from the archlinux pkgbuild): ./configure --prefix=/usr --with-curses --enable-readline \ --with-bash-malloc --with-installed-readline \ --bindir=/bin --mandir=/usr/share/man --infodir=/usr/share/info
Setting READLINE_POINT isn't always applied (4.0.24)
Hello,
If I try to change READLINE_LINE and READLINE_POINT from a
function bound via bind -x, then setting READLINE_POINT is not
applied every second time I invoke the function. Instead, the
cursor is placed at the end of the line.
Simple test case:
test_rl () {
READLINE_LINE="$READLINE_LINE#edited"
READLINE_POINT=3
}
bind -x '"\ew": test_rl'
And keep hitting \ew... every first time the cursor is placed at
position 3, every second time it ends up at the end of the line.
Is this the intended behavior or is it a bug?
Also, is it intended that the modified line is drawn on a new
line? For example, if I wrote a function that increments the word
at READLINE_POINT if it contains only digits, and i wanted to
increase a value by hitting a keyseq five times, I'd end up with
five lines being printed in my terminal. I'd love to see this work
like readline's own editing functions (e.g. upcase-word) or macros
that edit the line without printing it again on a new line. But
maybe I just misinterpreted the purpose of this new feature. If
so, could you explain it's intended purpose?
Regards,
Henning
Re: Setting READLINE_POINT isn't always applied (4.0.24)
Chet Ramey wrote:
> Henning Bekel wrote:
>> Hello,
>> If I try to change READLINE_LINE and READLINE_POINT from a
>> function bound via bind -x, then setting READLINE_POINT is not
>> applied every second time I invoke the function. Instead, the
>> cursor is placed at the end of the line.
>>
>> Simple test case:
>>
>> test_rl () {
>> READLINE_LINE="$READLINE_LINE#edited"
>> READLINE_POINT=3
>> }
>>
>> bind -x '"\ew": test_rl'
>>
>> And keep hitting \ew... every first time the cursor is placed
>> at position 3, every second time it ends up at the end of the
>> line.
>>
>> Is this the intended behavior or is it a bug?
>
> It's a bug. A fix will appear as a patch to bash-4.0.
Thanks!
>> Also, is it intended that the modified line is drawn on a new
>> line? For example, if I wrote a function that increments the
>> word at READLINE_POINT if it contains only digits, and i wanted
>> to increase a value by hitting a keyseq five times, I'd end up
>> with five lines being printed in my terminal. I'd love to see
>> this work like readline's own editing functions (e.g.
>> upcase-word) or macros that edit the line without printing it
>> again on a new line. But maybe I just misinterpreted the
>> purpose of this new feature. If so, could you explain it's
>> intended purpose?
>
> It's intended. Since the command executed as a result of `bind
> -x' is an arbitrary one that can do anything it wants to the
> display, it's better to completely redraw the line.
I already assumed this, just thought I'd make sure, thanks.
> I wonder if we could specify whether or not to completely redraw
> the line with a return status.
As far as I see it there hasn't been a reason to return a specific
value from a function bound via -x in the past, has there? Still,
maybe some users have done so out of principle (as in "I just
always return 0 on success for any function"), and thus giving
meaning to the return value might result in unexpected behaviour
for existing code... not sure about this.
Alternatively, couldn't another option like '-X' be introduced for
bind to explicitly request not to redraw the line completely? Or
would you consider this feature creep?
Best Regards,
Henning
trap ERR shows inconsistent behaviour
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=i686 -mtune=generic -O2
-pipe
uname output: Linux helios 2.6.30-ARCH #1 SMP PREEMPT Mon Jul 20 11:20:32 UTC
2009 i686 AMD Athlon(tm) XP 2600+ AuthenticAMD GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 4.0
Patch Level: 24
Release Status: release
Description:
When set -E is active functions inherit the ERR trap, however it will not
be executed if the failed command is part of a comman executed in a ||
list.
If the failing command is part of a function, which is called as first
part of ||, the ERR trap is not executed (call_func1), however if the
function is
called by eval it will be executed (call_func2).
If trap 'return 1' ERR is set and the eval is wrapped in a list the second
part of || will be executed(call_func3), without the list the trap will be
executed
again.
Repeat-By:
set -E
trap 'return $?' ERR
func(){
echo "entering func"
false
echo "after false"
}
call_func1() {
echo 'PRE CALL func1||...'
func || ret=$?
echo "POST CALL "
}
call_func2() {
echo 'PRE CALL eval func1||...'
eval func || ret=$?
echo "POST CALL $ret"
}
call_func3() {
echo 'PRE CALL (eval func1)||...'
(eval func) || ret=$?
echo "POST CALL $ret"
}
call_func1
call_func2
call_func3
Fix:
I am not sure if this is a bug, if this behaviour is intented a clarifying
line in the description of trap would be useful. If not, is there any way
to use "return $?" with the ERR trap, but stop it from completely
unravelling the
call chain?
Re: Question (and maybe, a suggestion)
Pablo RodrÃguez Fernández wrote: > Why there are some keyboard shortcuts that don't appear on man > and web page manual? I've found some shortcuts very useful (and > widely knowed by bash users) on this blog: > http://linuxhelp.blogspot.com/2005/08/bash-shell-shortcuts.html > and most of them are on man, but some of them are not or are not > described like really works, for example Ctrl+C to stop a > process or ctrl+D to exit and logout a process and bash, > respectively (on job control environment). So: > > Are these shortcuts non-standards on bash? If they are, why are > they not explained on man or web manual These keys are defined and handled by your terminal, not bash. Ctrl+C sends a SIGINT signal. See man bash, section SIGNALS on how bash handles it. Ctrl+D sends EOF (end of file). See the output of 'stty -a' for other keys that are handled by your terminal before they even reach bash. Note that for example Ctrl+S stops execution, while Ctrl+Q resumes it. In the bash manual you'll find that Ctrl+S is bound to the readline function forward-search-history by default, but since the terminal already handles this keyseq, it never 'gets through' to bash unless you'd disable/change it for your terminal via stty. So these keys aren't documented in man bash since they aren't part of bash (or readline for that matter). Regards, Henning
possible write to an invalid address
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=i686 -mtune=generic -O2 -pipe -ggdb uname output: Linux helios 2.6.31-ARCH #1 SMP PREEMPT Sat Sep 26 02:39:09 CEST 2009 i686 AMD Athlon(tm) XP 2600+ AuthenticAMD GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 4.0 Patch Level: 33 Release Status: release Description: When bash_dequote_filename() is called with text ending with a backslash and double quote as quote_char, it writes beyond the memory allocated for ret, thus corrupting memory. Repeat-By: This was originally reported as bash crashing when trying to tab-complete: wine "c:\windows\ I can replicate this behaviour on my i686 system. Fix: bash_dequote_filename() checks if *p is '\0' after writing it to r and later writes another '\0' behind that. Move the check before the write: --- bash-4.0.orig/bashline.c2009-10-04 15:06:46.0 +0200 +++ bash-4.0/bashline.c 2009-10-04 15:07:03.0 +0200 @@ -3223,9 +3223,9 @@ bash_dequote_filename (text, quote_char) else if (quoted == '"' && ((sh_syntaxtab[p[1]] & CBSDQUOTE) == 0)) *r++ = *p; - *r++ = *++p; - if (*p == '\0') + if (*++p == '\0') break; + *r++ = *p; continue; } /* Close quote. */
Re: How to change the command completion behavior in bash
On Sun, Nov 15, 2009 at 08:31:38PM -0600, Peng Yu wrote: > If I have the following in the command line, > > ~/.bash > > when I type , it will become /home/my_user_name/.bash > > I'm wondering if it is possible to configure bash command completion, > so that it will still be '~/.bash' > Add set expand-tilde off to your ~/.inputrc . However off is the default value, so you could try to find out where it is set to on and remove that. See "Readline Variables" in man bash.
Re: Logically equivalent statements output different results. Suspect problem with 'pipe'.
On Tue, 02.03.2010 um 15:41 +0530, Kalidas Yeturu wrote: > Logically equivalent statements output different results. Suspect > problem with 'pipe'. > This is not a bug, quoting man bash: > Each command in a pipeline is executed as a separate process (i.e., > in a subshell). http://mywiki.wooledge.org/BashFAQ/024 covers this with more details.
Conflicts between "complete" and "complete-filename"
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' - DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' - DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' - DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=i686 - mtune=generic -O2 -pipe uname output: Linux box 2.6.33-ARCH #1 SMP PREEMPT Thu May 13 12:06:25 CEST 2010 i686 AMD Athlon(tm) XP 2200+ AuthenticAMD GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 4.1 Patch Level: 7 Release Status: release Description: When the first word of the command line is a path containing slashes and ending in a slash or a partial filename of a non-executable file, if completion is attempted first via the readline function "complete" and after that with "complete-filename", then completion fails and "complete-filename" behaves similar to "complete" in that it only matches executable files and directories. Repeat-By: $ mkdir foo $ touch foo/bar $ bind '"\ew": complete-filename' $ foo # completes to foo/ $ foo/ # no matches, as expected, but then $ foo/<\ew> # no matches either, should complete to foo/bar likewise: $ foo# completes to foo/, I type 'b' and then do $ foo/b # no matches, as expected, but then $ foo/b<\ew> # no matches either, should complete to foo/bar whereas: $ fo# completes to foo/ $ foo/<\ew> # completes to foo/bar, just like $ foo/b<\ew> # completes to foo/bar, too To get out of "being stuck with regular complete": $ foo/b # "I'm stuck", so I back to "foo" $ foo # completes to foo/ $ foo/<\ew> # again completes to foo/bar alright The reason I want to complete to non-executable files is that I have a prompt command that reacts to "permission denied" and passes the path entered to xdg-open, so I can "open" files from the bash in an external application. Alternatively, is there a way to just have regular "complete" match non-executable filenames as well? As far as I understand it from the manual, there isn't... am I mistaken?
