[OT] graphic characters set
this command should starts the graphic character set (to create masks) $ tput smacs but, using aterm or Eterm, it does not work but it works using this form (lieing...) $ TERM=xterm tput smacs does anyone know where is the problem?
Re: coproc command doesn't accept NAME arg
Jan Schampera wrote: Tim Hatch wrote: Pilot:~/tmp/bash-4.0 tim$ coproc NAME ls [1] 18474 Pilot:~/tmp/bash-4.0 tim$ ./bash: line 32: NAME: command not found [1]+ Exit 127coproc COPROC NAME ls For some reason it expects a compound command on named coprocesses, http://bash-hackers.org/wiki/doku.php/syntax/keywords/coproc MSGID mailman.4819.1231909794.26697.bug-b...@gnu.org bash(1): If NAME is not supplied, the default name is COPROC. NAME must not be supplied if command is a simple command (see above); otherwise, it is interpreted as the first word of the simple command. Yes, it's not intuitive. It's an ambiguous parse otherwise. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: free: called with unallocated block argument
Chet Ramey wrote: p...@arcturus.universe wrote: Bash Version: 4.0 Patch Level: 0 Release Status: release Description: Problem with auto completion : ls[space][TAB] gives the follwing abort : malloc: /Users/chet/src/bash/src/parse.y:5561: assertion botched free: called with unallocated block argument last command: ls Aborting...Abandon If /etc/bash_completion is suppressed, problem disapears. My bash_completion is : $Id: bash_completion,v 1.872 2006/03/01 16:20:18 ianmacd Exp $ Repeat-By: ls[space] [TAB] or cd[space][TAB] and several other commands. My fault; I dropped a line from a submitted patch. The attached patch corrects it for me; see if it works for you. Chet It will be useful to have bash-4.0-patches available as it was for past versions. When are you planning to do that? Thanks. RR
Re: bash stuck in a loop defining arrays
Machine Type: i386-unknown-openbsd4.4
Bash Version: 4.0
Patch Level: 0
Description:
playing with the associative arrays, bash ends up in what appears
to be a busy loop that I cannot interupt with C-c
Repeat-By:
bash-4.0$ declare -A array
bash-4.0$ declare array[foo[bar]=bleh
bash-4.0$ array[foo]=bleh
You tricked the shell. Bash isn't smart enough to realize you're assigning
to an associative array, and performs quote removal on the assignment
before running `declare'.
What ends up happening is that the shell tries to create a variable named
'array[foo[bar]=bleh', since the dequoted word is no longer a valid
assignment statement. This leads to all sorts of weird behavior, since
some of the code's assumptions are violated.
The attached patch should catch the attempts to create invalid variables
and flag them as errors.
Chet
*** ../bash-4.0/builtins/declare.def2009-01-04 14:32:22.0 -0500
--- builtins/declare.def2009-02-25 09:41:35.0 -0500
***
*** 288,291
--- 288,297
}
}
+ else if (legal_identifier (name) == 0)
+ {
+ sh_invalidid (name);
+ assign_error++;
+ NEXT_VARIABLE ();
+ }
else
value = ;
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRUc...@case.eduhttp://tiswww.tis.case.edu/~chet/
Re: bash stuck in a loop defining arrays
On Wed, Feb 25, 2009 at 4:46 PM, Chet Ramey chet.ra...@case.edu wrote: Machine Type: i386-unknown-openbsd4.4 Bash Version: 4.0 Patch Level: 0 Description: playing with the associative arrays, bash ends up in what appears to be a busy loop that I cannot interupt with C-c Repeat-By: bash-4.0$ declare -A array bash-4.0$ declare array[foo[bar]=bleh bash-4.0$ array[foo]=bleh You tricked the shell. Bash isn't smart enough to realize you're assigning to an associative array, and performs quote removal on the assignment before running `declare'. What ends up happening is that the shell tries to create a variable named 'array[foo[bar]=bleh', since the dequoted word is no longer a valid assignment statement. This leads to all sorts of weird behavior, since some of the code's assumptions are violated. The attached patch should catch the attempts to create invalid variables and flag them as errors. Chet ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU c...@case.edu http://tiswww.tis.case.edu/~chet/ Thanks, unfortunately it seems that this patch isn't enough as it also happens with a simpler test case: bash-4.0$ declare -A array bash-4.0$ declare array[foo]=bar
examples/loadable/finfo.c missing cast
imadev:~$ enable -f /var/tmp/bash-4.0/examples/loadables/finfo finfo imadev:~$ ls -l .bashrc -rw-r--r-- 1 wooledgpgmr 331 Sep 16 14:30 .bashrc imadev:~$ finfo -s .bashrc 316732948 imadev:~$ finfo -s .bashrc 317115222 --- finfo.c.origWed Feb 25 10:07:12 2009 +++ finfo.c Wed Feb 25 10:04:45 2009 @@ -357,7 +357,7 @@ else printf(%d\n, st-st_gid); } else if (flags OPT_SIZE) - printf(%ld\n, st-st_size); + printf(%ld\n, (long) st-st_size); return (0); } The other use of st-st_size (in printst() line 276) is already cast.
crash encountered. repeatable.
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 -O3
-march=native
uname output: Linux 2.6.28.5 #1 Mon Feb 16 10:28:48 MST 2009 i686 GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 4.0
Patch Level: 0
Release Status: release
Description:
Crash occurs when using bash-completion 20060301
to complete a cd command to a directory.
bash 4.0; readline 6.0 and bash-completion 20060301 are installed.
The problem does not happen when bash-completion scripts are not loaded.
http://www.caliban.org/files/bash/bash-completion-20060301.tar.bz2
# set -x
# cd /usr/b+ local 'IFS=
' cur=/usr/b i j k
+ [[ /usr/b == ?(\\)\$* ]]
+ '[' -z '' ']'
+ _filedir -d
+ local 'IFS=
' xspec
+ _expand
+ '[' /usr/b '!=' /usr/b ']'
+ [[ /usr/b == \~*/* ]]
+ [[ /usr/b == \~* ]]
+ '[' -d = -d ']'
+ COMPREPLY=(${comprep...@]:-} $( compgen -d -- $cur ))
++ compgen -d -- /usr/b
+ return 0
+ return 0
malloc: /Users/chet/src/bash/src/parse.y:5561: assertion botched
free: called with unallocated block argument
last command: set -x
Aborting...Aborted
Repeat-By:
type cd /usr/b then press tab
Re: bash stuck in a loop defining arrays
Thanks, unfortunately it seems that this patch isn't enough as it also happens with a simpler test case: bash-4.0$ declare -A array bash-4.0$ declare array[foo]=bar That's actually a different problem, a fix for which I was thinking about before receiving your message. :-) Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://tiswww.tis.case.edu/~chet/
Re: free: called with unallocated block argument
It will be useful to have bash-4.0-patches available as it was for past versions. When are you planning to do that? Thanks. I will release official bash-4.0 patches as I have a chance. The posts to the mailing list are to get fixes in peoples' hands quickly. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://tiswww.tis.case.edu/~chet/
Re: crash encountered. repeatable.
Machine Type: i686-pc-linux-gnu Bash Version: 4.0 Patch Level: 0 Release Status: release Description: Crash occurs when using bash-completion 20060301 to complete a cd command to a directory. bash 4.0; readline 6.0 and bash-completion 20060301 are installed. The problem does not happen when bash-completion scripts are not loaded. I posted a patch for this earlier. Look at http://lists.gnu.org/archive/html/bug-bash/2009-02/msg00153.html and see if it fixes things for you. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://tiswww.tis.case.edu/~chet/
Re: free: called with unallocated block argument
On Wednesday 25 February 2009 09:06:21 Roman Rakus wrote: It will be useful to have bash-4.0-patches available as it was for past versions. When are you planning to do that? Thanks. ive been adding them to Gentoo as Chet posts them ... http://sources.gentoo.org/app-shells/bash/files/bash-4.0-* (well, there might be one or two there that didnt come from Chet, so just read the patch header first :D) -mike signature.asc Description: This is a digitally signed message part.
large exit values (255)
seems there's a way to get bash to report exit values greater than 255 ... since it requires certain key presses, things in between ... means a key press rather than typing literally ... $ true $ echo 'enter ctrl+c $ echo $? 128 $ echo 'enter ctrl+c $ echo 'enter ctrl+c $ echo $? 128 $ true $ echo 'enter ctrl+d $ echo $? 258 $ true $ echo 'enter ctrl+d $ echo 'enter ctrl+c $ echo $? 386 that doesnt seem right to me :) the first test seems fine, and older versions of bash would set 258 for the second test (not sure if it's correct though), but the third test looks like a regression (not clearing exit status completely somewhere ?). -mike signature.asc Description: This is a digitally signed message part.
Re: Problem with function cd in bash 4.0
On Wednesday 25 February 2009 16:21:47 Chet Ramey wrote: Yep, it's a bug. Try the attached patch; it works for me. this introduces a bug of it's own though :/. you can no longer use ctrl+c to escape from unbalanced quotes. - type: echo ' - hit enter - hit ctrl+c over and over - bash still waits for the ' to be balanced Still not sure what extra stuff Linux runs to make this only fail there, but here's a patch that should fix it. seems to fix the issue on my system, thanks -mike
Re: bash-4.0: parser complains on `| {}' statement
Evgeniy Zhemchugov wrote:
Configuration Information
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=nocona -O2 -pipe -mtune=generic
uname output: Linux LFS 2.6.25.17 #7 SMP PREEMPT Tue Jan 20 22:40:20
MSK 2009 x86_64 Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz
GenuineIntel GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.0
Patch Level: 0
Release Status: release
Description:
Look at the following bash session:
$ { echo a; } | { read a; echo read: $a; }
bash: syntax error near unexpected token `}'
Expected behavior:
$ { echo a; } | { read a; echo read: $a; }
read: a
It works correctly with `21 |' instead of `|' or when the
right side does not contain braces. For example:
$ f() { read a; echo read: $a; }
$ { echo a; } | f
read: a
Try the attached patch; it works for me.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-4.0/parse.y 2009-01-08 08:29:12.0 -0500
--- parse.y 2009-02-25 17:25:56.0 -0500
***
*** 4450,4453
--- 4457,4461
case AND_AND:
case BANG:
+ case BAR_AND:
case DO:
case DONE:
Re: graphic characters set
On Feb 25, 4:20 am, Antonio Macchi antonio_mac...@alice.it wrote: this command should starts the graphic character set (to create masks) $ tput smacs but, using aterm or Eterm, it does not work but it works using this form (lieing...) $ TERM=xterm tput smacs does anyone know where is the problem? tput (and ncurses in general) is unrelated to bash. As I suggested, the place to start is in the terminfo manpage, where it describes line-drawing. (Look in that manpage for alternate, acs, etc). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: large exit values (255)
Mike Frysinger wrote: $ true $ echo 'enter ctrl+d $ echo $? 258 $ true $ echo 'enter ctrl+d $ echo 'enter ctrl+c $ echo $? 386 that doesnt seem right to me :) the first test seems fine, and older versions of bash would set 258 for the second test (not sure if it's correct though), but the third test looks like a regression (not clearing exit status completely somewhere ?). -mike Wow - how does one find that out? ;) IMHO everything above 255 is wrong. Maybe it could be fixed by making the $? expansion only respect the lower 8 bits. Though...weird :) (works in Bash 3 and 4 here) J.
Re: large exit values (255)
Mike Frysinger wrote: $ true $ echo 'enter ctrl+d $ echo $? 258 $ true $ echo 'enter ctrl+d $ echo 'enter ctrl+c $ echo $? 386 Just tested it, hopefully it's as easy as changing every itos (last_command_exit_value) to itos (last_command_exit_value 0xFF) in subst.c (seems 2 times). I don't provide a patch because it was a quick look and I don't know if any other parts of the code are involved (if yes, the patch would be awfully wrong). J.
