Re: Strange compgen behaviour
Mathias Dahl schrieb:
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.
Hm, compgen appears to behave strange if words contain whitespace.
However, you don't need it, as you build the list yourself. Try this:
_mm2() {
local cur files
cur=${COMP_WORDS[COMP_CWORD]}
files=$(find /home/mathias/Videos/movies/ -iname $cur*.avi -type
f -printf %P\n)
local IFS=$'\n'
COMPREPLY=($files)
}
Regards,
Bernd
--
Bernd Eggink
http://sudrala.de
Re: 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. This behavior is one of the consequences of the Austin Group's interpretation. Failures of user-specified subshells cause the shell to exit when set -e is in effect. The key piece of the interpretation was to widen the scope of commands that cause the shell to exit without an explicit exception from simple commands to all commands. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash 4 parse error on here-document in $()
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 The shell is allowed to do this. A here-document is supposed to be terminated by a line containing the delimiter followed by a newline, not EOF. However, the behavior is useful enough that I changed the parser to support it in bash-4.1. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Change in behaviour regarding subshell handling?
* Chet Ramey chet.ra...@case.edu [2009-09-24 08:29]: l. Changed behavior of shell when -e option is in effect to reflect consensus of Posix shell standardization working group. This behavior is one of the consequences of the Austin Group's interpretation. Failures of user-specified subshells cause the shell to exit when set -e is in effect. The key piece of the interpretation was to widen the scope of commands that cause the shell to exit without an explicit exception from simple commands to all commands. Thanks for the confirmation. Maybe CHANGES can be updated to list all the changes that were made as a consequence of the Austin Group's interpretation. -- Martin Michlmayr http://www.cyrius.com/
Re: Change in behaviour regarding subshell handling?
Thanks for the confirmation. Maybe CHANGES can be updated to list all the changes that were made as a consequence of the Austin Group's interpretation. Here's the new description of set -e: -e When this option is on, when any command fails (for any of the reasons listed in [xref to 2.8.1] or by returning an exit status greater than zero) the shell immediately shall exit with the following exceptions: 1) The failure of any individual command in a multi-command pipeline shall not cause the shell to exit. Only the failure of the pipeline itself shall be considered. 2) The -e setting shall be ignored when executing the compound list following the while, until, if, or elif reserved word, a pipeline beginning with the ! reserved word, or any command of an AND-OR list other than the last. 3) If the exit status of a compound command other than a subshell command was the result of a failure while -e was being ignored, then -e shall not apply to this command. This requirement applies to the shell environment and each subshell environment separately. For example, in set -e; (false; echo one) | cat; echo two the false command causes the subshell to exit without executing echo one; however, echo two is executed because the exit status of the pipeline (false; echo one) | cat is zero. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Strange compgen behaviour
Chet Ramey schrieb:
Hm, compgen appears to behave strange if words contain whitespace.
Well, it splits the argument to -W on $IFS as documented. What other
strange behavior do you see?
For example, this:
function _aha
{
local list=a b:c d:e f
COMPREPLY=($(IFS=: compgen -W $list))
}
complete -F _aha aha
Typing aha Tab cycles through 6 items a, b, c, d, e, f, whereas I
would expect 3 items 'a b', 'c d', 'e f'. It looks like compgen splits
the argument to -W on $IFS _and_ whitespace. Or am I missing something?
Regards,
Bernd
--
Bernd Eggink
http://sudrala.de
Re: Strange compgen behaviour
Bernd Eggink wrote:
Chet Ramey schrieb:
Hm, compgen appears to behave strange if words contain whitespace.
Well, it splits the argument to -W on $IFS as documented. What other
strange behavior do you see?
For example, this:
function _aha
{
local list=a b:c d:e f
COMPREPLY=($(IFS=: compgen -W $list))
}
complete -F _aha aha
Typing aha Tab cycles through 6 items a, b, c, d, e, f, whereas I
would expect 3 items 'a b', 'c d', 'e f'. It looks like compgen splits
the argument to -W on $IFS _and_ whitespace. Or am I missing something?
Hmmm...let me take a look.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: string format
given below will work except tab at beginning. echo Hello, how are you doing today? | tr -s \n Thanks, Mahaveer +91 9052000707 On Thu, Sep 24, 2009 at 12:33 AM, eatsubway koski...@gmail.com 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 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. -- Thanks, Mahaveer
Re: Strange compgen behaviour
On Thu, 24 Sep 2009, Bernd Eggink wrote:
Chet Ramey schrieb:
Hm, compgen appears to behave strange if words contain whitespace.
Well, it splits the argument to -W on $IFS as documented. What other
strange behavior do you see?
For example, this:
function _aha
{
local list=a b:c d:e f
COMPREPLY=($(IFS=: compgen -W $list))
That expands to:
COMPREPLY=( a b c d e f )
}
complete -F _aha aha
Typing aha Tab cycles through 6 items a, b, c, d, e, f, whereas I would
expect 3 items 'a b', 'c d', 'e f'. It looks like compgen splits the argument
to -W on $IFS _and_ whitespace. Or am I missing something?
--
Chris F.A. Johnson, webmaster http://woodbine-gerrard.com
===
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Re: bash 4 parse error on here-document in $()
Thank you for setting me straight! I had checked the POSIX spec before sending the report but missed the part about the delimiter having to be immediately followed by newline. Martin On 09/24/2009 06:39 AM, Chet Ramey wrote: 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=$(catEOF foo bar EOF) Ctrl+D -bash: unexpected EOF while looking for matching `)' -bash: syntax error: unexpected end of file The shell is allowed to do this. A here-document is supposed to be terminated by a line containing the delimiter followed by a newline, not EOF. However, the behavior is useful enough that I changed the parser to support it in bash-4.1. Chet
Bug in array populating does not respect quotes
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDI$
uname output: Linux bristol 2.6.31 #10 SMP Thu Sep 10 17:59:29 CEST
2009 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.0
Patch Level: 33 (debian bash-4.0-7)
Release Status: release
Description:
When populating an array from a string in a variable does not
handle quotes.
Repeat-By:
~$ declare -a samplearray
~$ samplearray=( x y 'z k')
~$ echo ${samplearray[2]}
z k
~$ samplestring=x y 'z k'
~$ samplearray=( $samplestring )
~$ echo ${samplearray[2]}
'z
Re: Bug in array populating does not respect quotes
On Thursday 24 September 2009 16:38:12 David Martin wrote:
Description:
When populating an array from a string in a variable does not
handle quotes.
Repeat-By:
~$ declare -a samplearray
~$ samplearray=( x y 'z k')
~$ echo ${samplearray[2]}
z k
~$ samplestring=x y 'z k'
~$ samplearray=( $samplestring )
~$ echo ${samplearray[2]}
'z
Not a bug. This is expected behavior. To do what you want, use eval:
~$ samplestring=x y 'z k'
~$ eval samplearray=( $samplestring )
~$ echo ${samplearray[2]}
z k
--
D.
Re: Bug in array populating does not respect quotes
On Thu, 24 Sep 2009, David Martin wrote:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDI$
uname output: Linux bristol 2.6.31 #10 SMP Thu Sep 10 17:59:29 CEST
2009 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.0
Patch Level: 33 (debian bash-4.0-7)
Release Status: release
Description:
When populating an array from a string in a variable does not
handle quotes.
Repeat-By:
~$ declare -a samplearray
~$ samplearray=( x y 'z k')
~$ echo ${samplearray[2]}
z k
~$ samplestring=x y 'z k'
~$ samplearray=( $samplestring )
eval samplearray=( $samplestring )
~$ echo ${samplearray[2]}
'z
--
Chris F.A. Johnson, webmaster http://woodbine-gerrard.com
===
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Re: Strange compgen behaviour
Hm, compgen appears to behave strange if words contain whitespace.
However, you don't need it, as you build the list yourself. Try this:
_mm2() {
local cur files
cur=${COMP_WORDS[COMP_CWORD]}
files=$(find /home/mathias/Videos/movies/ -iname $cur*.avi -type
f -printf %P\n)
local IFS=$'\n'
COMPREPLY=($files)
}
Ah, you're right of course, I can do the matching myself. I have yet
another version working now (had to change your latest suggestion and
use grep for matching because -name does not like full paths which
becomes the case here):
_mm() {
local cur files
COMPREPLY=()
cur=${COMP_WORDS[COMP_CWORD]}
files=$(find /home/mathias/Videos/movies/ -iname *.avi -type f -
printf %p\n | grep ${cur})
local IFS=$'\n'
COMPREPLY=(${files})
}
complete -o filenames -F _mm mm
Now, this works almost. The remaining problem is that because `find'
finds file in subdirs (which I want, otherwise I could add the -
maxdepth option) as well, the `-o filenames' argument to `complete'
does not play well with it. I see the names of files in subdirs listed
when I type TAB (without path) but can never pick them without knowing
the name of the folder they are in. So I have to get rid of that
option, but then I have to shell quote the file name myself to handle
spaces, brackets of various sorts, comma characters etc. Will hunt for
such a function and see. There are all sorts of crazy helper functions
in /etc/bash_completion, of which I barely understand anything.
Thanks!
Re: Strange compgen behaviour
...but then I have to shell quote the file name myself to handle
spaces, brackets of various sorts, comma characters etc. Will hunt for
such a function and see. There are all sorts of crazy helper functions
in /etc/bash_completion, of which I barely understand anything.
I did not find any generic way to quote/escape file names so I
hardcoded some chars I know exist in my file names and used sed:
_mm() {
local cur files
COMPREPLY=()
cur=${COMP_WORDS[COMP_CWORD]}
files=$(find /home/mathias/Videos/movies/ -iname *.avi -type f -
printf %p\n | grep ${cur} | sed 's/\([\(\) ,]\)/\\\1/g')
local IFS=$'\n'
COMPREPLY=(${files})
}
complete -F _mm mm
However, I don't like it, is feels ugly and one of these days there
will be some other funky char in some filename... :(
/Mathias
