Re: bash, no slash
davide.chiar...@gmail.com wrote:
> hi all,
>
> I'm having a strange problem with my bash setup. I'm using bash 3.2.0
> on ubuntu.
> Basically, I can't type a slash ('/') any way I try.
> If I hit the slash key - nothing. Numeric keypad - nothing. I remapped
> the keyboard to assign that character to another key - it turns to a
> dead key.
> If, from within bash, I run any other shell, the slash key works
> properly.
> This is an old install of ubuntu. I remember at first having problems
> getting autocomplete to work and fiddling into some files. I don't
> recall exactly what I had to do, but It's the only thing I did that
> could have caused this problem.
> However, I think I've undone pretty much everything I did.
> any hints on what configuration file could be involved in this
> problem? I think I've run ot of ideas...
I'm almost positive that you've remapped / to another character (or a
command that has no discernible effect) in readline. Look at your
readline startup files. You can see your current key bindings with
`bind -p' from the bash prompt.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash-4.0-rc1 available for FTP
Hello, I ran some benchmarks of Bash 4.0-rc1. It is quite impressive! Here are the results. My computer is a Pentium M (running at 600 MHz for the test), running Linux 2.6.26 with libc6 version 2.7 and Debian bash-completion version 20080705. The figures are averages over 100 tests. Bash 3.2, without bash malloc: * eval `dircolors`: 0.636s * source /etc/bash_completion: 0.721s Bash 4.0, with bash malloc: * eval `dircolors`: 0.385s * source /etc/bash_completion: 41.651s (around 93% of the time is spent in function find_entry of lib/malloc/table.c) Bash 4.0, without bash malloc: * eval `dircolors`: 0.132s * source /etc/bash_completion: 0.703s We notice that on my computer, libc6's malloc is definitively faster than Bash's malloc. More interesting is the fact that the various improvements to command substitution have dramatically reduced its execution time (eval `dircolors` is now 4.8 times faster!). Thank you very much for this wonderful new version of Bash! Nicolas
Re: Bash-4.0-rc1 available for FTP
Nicolas wrote: > Hello, > > I ran some benchmarks of Bash 4.0-rc1. It is quite impressive! Here are the > results. Thanks. > Bash 4.0, with bash malloc: > * eval `dircolors`: 0.385s > * source /etc/bash_completion: 41.651s (around 93% of the time is spent in > function find_entry of lib/malloc/table.c) Bash versions other than `release' are built with extensive extra arena and allocation checking enabled in the bash malloc. The `find_entry' function is the primary interface to look up the record kept for each allocation. As you can imagine, bash takes quite a performance hit when this kind of allocation debugging is enabled. If the results are acceptable with allocation tracing and debugging on, they should be even better in the release version. If you'd like to experiment right now, you can recompile after disabling the `DEBUG' and `MALLOC_DEBUG' defines in Makefile. (Or you can just rebuild with `make DEBUG= MALLOC_DEBUG='.) > We notice that on my computer, libc6's malloc is definitively faster than > Bash's malloc. Let's not decide that just yet. :-) Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
if, -n
c...@notas:~$ echo $variable c...@notas:~$ variable=hello c...@notas:~$ if [ -n $variable ]; then echo true; fi true c...@notas:~$ if [ -z $variable ]; then echo true; fi c...@notas:~$ variable= c...@notas:~$ if [ -n $variable ]; then echo true; fi true c...@notas:~$ if [ -z $variable ]; then echo true; fi true c...@notas:~$ Can anybody explain to me this behaviour? I would expect not any output in the last command...? The variable is set to zero and there is the condition is still true...? thanks, Jakub -- View this message in context: http://www.nabble.com/if%2C--n-%3Cstring%3E-tp21764081p21764081.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: Bash-4.0-rc1 available for FTP
> Bash versions other than `release' are built with extensive extra arena > and allocation checking enabled in the bash malloc. Thanks for pointing this out. Here are the new results: Bash 4.0, with bash malloc: * eval `dircolors`: 0.138s * source /etc/bash_completion: 0.735s Bash 4.0, without bash malloc: * eval `dircolors`: 0.135s (slightly slower than with debugging on, I checked several times to be sure. This is very surprising...) * source /etc/bash_completion: 0.702s Without bash malloc, the results are close to the results with debugging on. The results with bash malloc are far better now, but still slightly behind those with libc malloc, on my computer. In addition, in builtins/evalstring.c, line 271, an itrace call is not enclosed between #if defined (DEBUG) and #endif, as it should be. With my computer at normal speed (with the 'ondemand' governor), starting a new shell (and running my .bashrc) now takes around 0.4s, while it took 0.6s with Bash 3.2. This is enough to feel a difference! Nicolas
Re: if, -n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to coubeatczech on 1/31/2009 7:24 AM:
> c...@notas:~$ variable=
> c...@notas:~$ if [ -n $variable ]; then echo true; fi
> true
This is equivalent to 'if [ -n ]; then echo true; fi'; in other words,
because there is only one argument ("-n"), and it is not empty, it is true.
You meant to use quotes, to guarantee that there are two arguments, as in:
if [ -n "$variable" ]; then echo true; fi
- --
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmFCUMACgkQ84KuGfSFAYCU6ACgj4hHK1Cxuk/gwI6QPo6xU0Ng
6KIAoMx3sk6bvV8YHGssez2s2vT7s45e
=VLoa
-END PGP SIGNATURE-
