Problem with bind -x
I noticed a problem with bind -x: readline re-prints the line if the
function is called when the cursor is not in the first line.
To reproduce it (and to understand what I mean, if it's not clear):
prompt$ myfunc () { :; }
prompt$ bind -x '\C-a:myfunc'
Now write a line that's long enough to wrap, then press C-a
prompt$ a
aaa
Results in this:
prompt$ a
prompt$ a
aaa
Similar results also happen with heredocs and any command that spans
multiple lines when it's recalled with previous-history
It appears that removing these two lines from display.c fixes it:
--- a/lib/readline/display.c
+++ b/lib/readline/display.c
@@ -1936,8 +1936,8 @@ rl_on_new_line ()
if (visible_line)
visible_line[0] = '\0';
- _rl_last_c_pos = _rl_last_v_pos = 0;
- _rl_vis_botlin = last_lmargin = 0;
+ /*_rl_last_c_pos = _rl_last_v_pos = 0;*/
+ /*_rl_vis_botlin = last_lmargin = 0;*/
if (vis_lbreaks)
vis_lbreaks[0] = vis_lbreaks[1] = 0;
visible_wrap_offset = 0;
I don't know if it breaks something else...
Hope this helps.
---
xoxo iza
Re: Possibly a bug
The behaviour on bash 4.2.53(1)-release seems to be different. For example $ ./history | his bash: his: command not found... [ Here I press enter to get back to the terminal. This wasn't the case on 4.3.x ] [1]+ Stopped ./history | his $ jobs -l [1]+ 4784 Stopped (tty input) ./history 4785 Exit 127| his $ fg ./history | his ^C $ jobs -l $ Bringing the process to foreground and sending SIGINT seems to clean the process from the job list. Is this sufficient? On Tue, Apr 21, 2015 at 3:14 AM, Chet Ramey chet.ra...@case.edu wrote: On 4/20/15 5:24 PM, Valentin Bajrami wrote: Hi Chet, I see. But how would I avoid this? Using Fedora 21 here and my command_not_found_handle() is It's hard to say without knowing what pk-command-not-found does. What does this do when you just run `his' from the command line and let it execute in the foreground? What happens when you run `fg' to try and bring that pipeline back into the foreground? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ -- Met vriendelijke groet, Valentin Bajrami
Problem with brace expansion
There appears to be a bug in bash when using a variable in curly brace
expansion, e.g., {1..$n}. I have put the two following test scripts in the
attached files looper1.sh and looper2.sh:
#looper1.sh
for i in {1..4}
do
echo i = $i
done
#looper2.sh
n=4
for i in {1..$n}
do
echo i = $i
done
Tests were done with bash, ksh, zsh, pdksh, dash and heirloom System V Bourne
sh with the following versions:
bash3.2.57(1)
bash4.3.33(1)
ksh version sh (ATT Research) 93u+ 2012-08-01
zsh 5.0.5 (x86_64-apple-darwin14.0)
pdksh stable 5.2.14
dashstable 0.5.8
sh ???
Results for bash (both versions give the same result); note that bash fails to
expand the curly brace expression in only the second case:
$ bash looper1.sh
i = 1
i = 2
i = 3
i = 4
$ bash looper2.sh
i = {1..4}
Repeating using ksh we get correct expansion of the curly braces:
$ ksh looper1.sh
i = 1
i = 2
i = 3
i = 4
$ ksh looper2.sh
i = 1
i = 2
i = 3
i = 4
And using zsh, the same result as for ksh:
$ zsh looper1.sh
i = 1
i = 2
i = 3
i = 4
$ zsh looper2.sh
i = 1
i = 2
i = 3
i = 4
Neither pdksh (which installs as ksh using homebrew) nor dash handle either
case correctly:
pdksh:
$ /usr/local/bin/ksh looper1.sh
i = {1..4}
$ /usr/local/bin/ksh looper2.sh
i = {1..4}
dash:
$ dash looper1.sh
i = {1..4}
$ dash looper2.sh
i = {1..4}
The System V sh from the heirloom project behaves the same way as pdksh and
dash (or more correctly, since System V is really the reference, pdksh and dash
behave the same way as SysV sh):
$ 5 sh looper1.sh
i = {1..4}
$ 5 sh looper2.sh
i = {1..4}
looper1.sh
Description: Binary data
looper2.sh
Description: Binary data
Re: Problem with brace expansion
On 04/21/2015 01:44 PM, Dr Alun J. Carr wrote: Tests were done with bash, ksh, zsh, pdksh, dash and heirloom System V Bourne sh with the following versions: bash 3.2.57(1) bash 4.3.33(1) ksh version sh (ATT Research) 93u+ 2012-08-01 zsh 5.0.5 (x86_64-apple-darwin14.0) pdksh stable 5.2.14 dash stable 0.5.8 sh??? You do realize, I hope, that brace expansion is not required by POSIX, and therefore there is no standard for what behavior it has, and it should be no surprise that pdksh, dash, and Bourne sh do not try to expand it. As for whether bash should expand $n into 4 prior to doing brace expansion, or whether brace expansion is attempted first but not recognizing $n as a valid bound devolves into no expansion, that is indeed a difference between ksh and bash. But bash is consistent with its documentation: The order of expansions is: brace expansion; tilde expansion, parameter and variable expansion, arithmetic expansion, and command substitution (done in a left-to-right fashion); word splitting; and pathname expanâ sion. so you cannot use a variable as a bound and still expect brace expansion to work, since variables aren't expanded yet. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Problem with brace expansion
On Tue, 21 Apr 2015, Dr Alun J. Carr wrote:
There appears to be a bug in bash when using a variable in curly
brace expansion, e.g., {1..$n}. I have put the two following test
scripts in the attached files looper1.sh and looper2.sh:
Brace expansion is done before variable expansion:
The order of expansions is: brace expansion; tilde expansion,
parameter and variable expansion, arithmetic expansion, and
command substitution (done in a left-to-right fashion); word
splitting; and pathname expansion.
Neither pdksh (which installs as ksh using homebrew) nor dash handle either
case correctly:
Neither pdksh nor dash has brace expansion.
--
Chris F.A. Johnson, http://cfajohnson.com
Re: Problem with brace expansion
On Tue, Apr 21, 2015 at 2:44 PM, Dr Alun J. Carr alun.j.c...@runbox.com
wrote:
There appears to be a bug in bash when using a variable in curly brace
expansion, e.g., {1..$n}. I have put the two following test scripts in the
attached files looper1.sh and looper2.sh:
#looper1.sh
for i in {1..4}
do
echo i = $i
done
#looper2.sh
n=4
for i in {1..$n}
do
echo i = $i
done
Tests were done with bash, ksh, zsh, pdksh, dash and heirloom System V
Bourne sh with the following versions:
bash3.2.57(1)
bash4.3.33(1)
ksh version sh (ATT Research) 93u+ 2012-08-01
zsh 5.0.5 (x86_64-apple-darwin14.0)
pdksh stable 5.2.14
dashstable 0.5.8
sh ???
Results for bash (both versions give the same result); note that bash
fails to expand the curly brace expression in only the second case:
$ bash looper1.sh
i = 1
i = 2
i = 3
i = 4
$ bash looper2.sh
i = {1..4}
Repeating using ksh we get correct expansion of the curly braces:
$ ksh looper1.sh
i = 1
i = 2
i = 3
i = 4
$ ksh looper2.sh
i = 1
i = 2
i = 3
i = 4
And using zsh, the same result as for ksh:
$ zsh looper1.sh
i = 1
i = 2
i = 3
i = 4
$ zsh looper2.sh
i = 1
i = 2
i = 3
i = 4
Neither pdksh (which installs as ksh using homebrew) nor dash handle
either case correctly:
pdksh:
$ /usr/local/bin/ksh looper1.sh
i = {1..4}
$ /usr/local/bin/ksh looper2.sh
i = {1..4}
dash:
$ dash looper1.sh
i = {1..4}
$ dash looper2.sh
i = {1..4}
The System V sh from the heirloom project behaves the same way as pdksh
and dash (or more correctly, since System V is really the reference, pdksh
and dash behave the same way as SysV sh):
$ 5 sh looper1.sh
i = {1..4}
$ 5 sh looper2.sh
i = {1..4}
Bash performs brace expansion before variable expansion and thus does not
support the feature that zsh and ksh have which do variable expansion
before brace expansion.
To use a variable, use C-style for loops:
for ((i = 1; i = 4; i++))
--
Visit serverfault.com to get your system administration questions answered.
