Re: filename pattern case-insensitive, but why?
Mike Stroyan wrote:
On Tue, Sep 22, 2009 at 02:36:30AM -0700, thahn01 wrote:
Hello, If I try something like:
$ touch a.c b.c A.c
$ ls [a-z]*.c
a.c A.c b.c
then I get A.c in the output, even if no capital letters are to be found.
The [a-z] range expression matches characters between a and z in the
current locale's collation order. The collation order for en_US.UTF-8 and
other locales has uppercase and lowercase alphabetic characters together.
So in those locales your range includes 'a' through 'z' and 'A' through
'Y'. You can change the locale to C or POSIX to get plain ascii
collation order. You can see the collation order using the sort command.
for c in {32..126}; do eval printf '%c - %d\n' $(printf $'%o' $c)
$c;done | sort -k 1.1,1.1
for c in {32..126}; do eval printf '%c - %d\n' $(printf $'%o' $c)
$c;done | LANG=C sort -k 1.1,1.1
The collation order lists 'a' before 'A', but actually lets a later
character break a tie between otherwise equal uppercase and lowercase
characters. Sort will arrange 'a1', 'A1', 'a2', and 'A2' with the '1'
vs. '2' characters acting as a tiebreaker.
...and that it is why instead of using
$ ls [a-z]*.c
you should use
$ ls [[:lower:]]*.c
Re: Bash 4.0.0 crash on completion
André Johansen wrote: Description: When using tab-completion, Bash crashes. I'm using the bash_completion package from http://www.caliban.org/bash/index.shtml#completion. ... Repeat-By: Press tab to get a completion; if Bash enters a programmed completion (i.e. not a simple file name or variable name expansion), Bash crashes. Apply the patches (ftp://ftp.gnu.org/pub/gnu/bash/bash-4.0-patches/ ). I believe this was fixed by patch 002. -- View this message in context: http://www.nabble.com/Bash-4.0.0-crash-on-completion-tp22783625p22784131.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: Completion crashes the shell
Chris F.A. Johnson-3 wrote:
This completion function worked in previous versions, but fails in
bash4.0 when I press TAB:
_cpsh() {
COMPREPLY=( `
cd $HOME/scripts || return 3
printf %s\n ${COMP_WORDS[$COMP_CWORD]}*-sh`
)
COMPREPLY=( ${comprep...@]%-sh} )
}
complete -F _cpsh cpsh
This is what happens:
$ cpsh TAB
malloc: ./parse.y:5563: assertion botched
free: called with unallocated block argument
last command: _cpsh() {
COMPREPLY=( `
cd $HOME/scripts || return 3
printf %s\n ${COMP_WORDS[$COMP_CWORD]}*-sh`
)
COMPREPLY=( ${comprep...@]%-sh} )
}
Aborting...Aborted
Have you applied the tab completion patch that Chet provided here:
http://lists.gnu.org/archive/html/bug-bash/2009-02/msg00153.html
http://lists.gnu.org/archive/html/bug-bash/2009-02/msg00153.html
--
View this message in context:
http://www.nabble.com/Completion-crashes-the-shell-tp22294334p22294834.html
Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: Problem with function cd in bash 4.0
Chet Ramey wrote: Interesting. This happens only on Linux. FreeBSD, MacOS X, and Solaris all interrupt and return to $PS1. Chet Actually, this was happening for me on Solaris too, so looks like not just a Linux thing. But your patch fixed the issue on Solaris as well. Richard -- View this message in context: http://www.nabble.com/Problem-with-function-cd-in-bash-4.0-tp22171999p0451.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: Problem with function cd in bash 4.0
Chet Ramey wrote: 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 Ah yes, that was indeed the problem. Fixed for me as well now. Thanks. -- View this message in context: http://www.nabble.com/Problem-with-function-cd-in-bash-4.0-tp22171999p22191924.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
