Re: filename pattern case-insensitive, but why?
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.
--
Mike Stroyan m...@stroyan.net
Re: Strange compgen behaviour
Mathias Dahl schrieb:
Hi fellow bashers!
I am trying to add some completion to a command. The completion should
list all movies I have in a certain folder, regardless if I am in that
folder or not. I have kind of got it to work in several variants but
all have some issue. The current problem I am looking at is very
strange. I have isolated it down to a strange behaviour with compgen.
Let's see if I can describe it clearly enough:
zf contains the list of movie file names
zc is the current input, in my case /home/mathias/Videos/movies/H
$ compgen -W ${zf} -- ${zc}
Here is the output:
/home/mathias/Videos/movies/Harry.Potter...
/home/mathias/Videos/movies/Harry.Potter...
/home/mathias/Videos/movies/Harry.Potter...
/home/mathias/Videos/movies/Harry.Potter...
/home/mathias/Videos/movies/Harry.Potter...
/home/mathias/Videos/movies/Brazil (Terry Gilliam, 1985).avi
/home/mathias/Videos/movies/Ice.Age.2...
/home/mathias/Videos/movies/True.Blood.S01...
/home/mathias/Videos/movies/True.Blood.S01...
It depends heavily on how the variables IFS and zf are set. From 'man bash':
-W wordlist
The wordlist is split using the characters in the IFS special
variable as delimiters, and each resultant word is expanded.
The possible completions are the members of the resultant
list which match the word being completed.
You didn't say how you assigned the variable zf. If you simply did
zf=$(ls /home/mathias/Videos/movies/*), the Brazil line will be split
into 4 words instead of 1. However, your output suggest that you somehow
managed to combine all file names to a single word starting with
Harry.Potter.
Try this: Choose a character which doesn't appear in any file name,
e.g., ':'.
list=$(printf %s: /home/mathias/Videos/movies/*)
IFS=: compgen -W $list -- $zc
Regards,
Bernd
--
Bernd Eggink
http://sudrala.de
Re: Strange compgen behaviour
It depends heavily on how the variables IFS and zf are set. From 'man bash':
-W wordlist
The wordlist is split using the characters in the IFS special
variable as delimiters, and each resultant word is expanded.
The possible completions are the members of the resultant
list which match the word being completed.
I used a newline since the original listing comes from `find'.
You didn't say how you assigned the variable zf. If you simply did
zf=$(ls /home/mathias/Videos/movies/*), the Brazil line will be split
into 4 words instead of 1. However, your output suggest that you somehow
managed to combine all file names to a single word starting with
Harry.Potter.
Yes, that could be the case.
Try this: Choose a character which doesn't appear in any file name,
e.g., ':'.
list=$(printf %s: /home/mathias/Videos/movies/*)
IFS=: compgen -W $list -- $zc
That works, thanks! However, I also want files from sub folders to be
found, so I use `find' to list them.
Here is my latest attempt, using the idea of setting IFS to `:':
_mm2() {
local cur files
COMPREPLY=()
cur=${COMP_WORDS[COMP_CWORD]}
files=$(find /home/mathias/Videos/movies/ -iname '*.avi' -type f -
printf %p:)
OLDIFS=$IFS
IFS=:
COMPREPLY=($(compgen -W ${files} -- ${cur}))
IFS=$OLDIFS
}
complete -o filenames -F _mm2 mm
Looks like it should work but it does not. Typing mmSPCTAB gives
the listing and completes all the way to the path, but if I add B
again it does not match Brazil.
Any ideas?
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
Change in behaviour regarding subshell handling?
I noticed that bash has changed behaviour regarding subshell handling, breaking a script of mine. Now a script with -e fails when a subshell fails whereas it didn't before. I looked at the CHANGES file and couldn't find anything about this, so I wanted to ask if this change was intentional or if this is a bug. In fact, there's something in CHANGES that might be relevant but the description isn't really clear at all: l. Changed behavior of shell when -e option is in effect to reflect consensus of Posix shell standardization working group. Anyway, the test program and output is below. Take this script: set -e set -x echo 1 (echo x | grep -v x) echo 2 On Debian lenny with 3.2.39(1)-release: foobar:~# bash t + echo 1 1 + grep -v x + echo x + echo 2 2 On Debian testing with 4.0.28(1)-release: foobar:~# bash t + echo 1 1 + echo x + grep -v x With dash (same output for lenny and testing): foobar:~# dash t + echo 1 1 + echo x + grep -v x + echo 2 2 -- Martin Michlmayr http://www.cyrius.com/
string format
hello, i have a simple question. I have a string which i would like to format by replacing spaces with newlines and tabs, and also adding a tab to the beginning. the variable... MyVar=Hello, how are you doing today? I would like to print this Hello, how are you doing today? -- View this message in context: http://www.nabble.com/string-format-tp25531252p25531252.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
bash 4 parse error on here-document in $()
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables uname output: Linux mslaptop 2.6.30.5-43.fc11.i586 #1 SMP Thu Aug 27 21:18:54 EDT 2009 i686 i686 i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 4.0 Patch Level: 23 Release Status: release Description: Bash 4.0 errors on a here-document enclosed in $(). For example: x=$(cat EOF foo bar EOF) Ctrl+D -bash: unexpected EOF while looking for matching `)' -bash: syntax error: unexpected end of file Repeat-By: Save the following script in a file named t.sh, execute the file and observe the parse error: ./t.sh: line 7: unexpected EOF while looking for matching `)' ./t.sh: line 13: syntax error: unexpected end of file #!/bin/bash x=`cat EOF foo bar EOF` y=$(cat EOF foo bar EOF) [ $x != $y ] exit 1
Re: string format
On Wed, Sep 23, 2009 at 12:03:56PM -0700, eatsubway wrote: hello, i have a simple question. I have a string which i would like to format by replacing spaces with newlines and tabs, and also adding a tab to the beginning. The printf builtin will do that easily. If you give it a format with one argument then it will repeat that format for each of multiple arguments. printf \t%s\n $MyVar If you really want to only break up your string at spaces then you will want to momentarily change IFS to just instead of the default that matches spaces, tabs, and newlines. Be sure to put IFS back to the default for the benefit of later parts of your shell script that expect the default. You can do that with another assignment or with a subshell like this- ( IFS= ; printf \t%s\n $MyVar ) -- Mike Stroyan m...@stroyan.net
