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
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 <
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.
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/
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: 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 mm 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: 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