Re: extglob pattern matching does not work as in bash 2
o...@sernet.de wrote: > Description: > After updating to a new distribution with bash version 3.x entglob > does > not work like in bash version 2.x. Thanks for the report. This problem is specific to pattern substitution and patterns that begin with `*('. It will be fixed in bash-4.0. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: ZSH like command line completion
Mithu2 wrote: > Hi, > > I know in Bash the file completion can be set to provide a menu-list of > possible files. This seems to be the default behaviour. On the other hand, > I could add: > > bind 'TAB:menu-complete' > > to my .bashrc which allows cycling through the list of completions. But > these two options are mutually exclusive. > > Is is possible to activate BOTH on the same key (tab)? This is the default > behaviour in ZSH where the first tab will menu-list all the completions and > then the next tab starts cycling through the possible completions. (I > already have > > bind "set show-all-if-ambiguous on" > > to make the menu appear on the first tab) The menu-complete implementation in bash-4.0 will honor the setting of show-all-if-ambiguous. If that is enabled, menu-complete will print the possible completions on the first tab as well as begin to cycle through the completion set. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: ${parameter+word} not documented in bash.info or bash(1)
> "Paul" == Paul Jarc writes: Paul> "Martin Schwenke" wrote: >> Neither bash.info or bash(1) documents parameter expansion of >> the form: >> >> ${parameter+word} Paul> It's documented, but it's easy to miss. Just before the Paul> list of parameter expansion forms is this paragraph: Paul>In each of the cases below, word is subject to tilde Paul>expansion, parameter expansion, command substitution, Paul>and arithmetic expansion. When not performing Paul>substring expansion, bash tests for a parameter that Paul>is unset or null; omitting the colon results in a Paul>test only for a parameter that is unset. Ouch! Can I suggest that this documentation could be improved, since it is so easy to miss and that I missed it at least 4 times when actually looking for it? ;-) I think the main issue is that when people use reference documentation they tend to scan through it to find what they're looking for. My suggestion would be to break the list of expansions before substring expansion and insert a paragraph containing the above text. Then, rather than necessarily listing all of the examples as the standard does, perhaps provide a single example that compares the effect of using the colon with the effect of excluding it. The bash documentation is so long that I don't think adding this will make it too long... :-) peace & happiness, martin
Re: ${parameter+word} not documented in bash.info or bash(1)
Martin Schwenke wrote: > Paul Jarc writes: > > It's documented, but it's easy to miss. Just before the > > list of parameter expansion forms is this paragraph: > > > >In each of the cases below, word is subject to tilde > >expansion, parameter expansion, command substitution, > >and arithmetic expansion. When not performing > >substring expansion, bash tests for a parameter that > >is unset or null; omitting the colon results in a > >test only for a parameter that is unset. > > Ouch! Can I suggest that this documentation could be improved, since > it is so easy to miss and that I missed it at least 4 times when > actually looking for it? ;-) Let me cast a vote for this too. I know what it does but have also found myself "looking for it" specifically because I am looking for ":" and not "colon". If the colon character ':' were mentioned in the description I think that would make this much clearer. Let me suggest that something similar to the following addition would help here. is unset or null; omitting the colon (':') results in a test only for a parameter that is unset. Then searches on ":" would also find that descriptive text too. Bob
wrong lineno inside trap?
I wrote a test program test.sh: trap ' echo this is line 3, but LINENO=$LINENO ' 0 echo this is line 7, and LINENO=$LINENO --- when I ran it I got $ sh /tmp/test.sh this is line 7, and LINENO=7 this is line 3, but LINENO=11 My bash version is $ sh --version GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. Is this a known problem? Thanks. -- View this message in context: http://www.nabble.com/wrong-lineno-inside-trap--tp21383479p21383479.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: wrong lineno inside trap?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to peter360 on 1/9/2009 6:07 PM: > trap ' > > echo this is line 3, but LINENO=$LINENO > > ' 0 > > echo this is line 7, and LINENO=$LINENO > Is this a known problem? Thanks. In general, LINENO handling is inconsistent among shells. The presence of single vs. multi-line constructs, eval, here-docs, and shell functions cause different shells to give different values to LINENO. For more documentation on this, see: http://www.gnu.org/software/autoconf/manual/html_node/Special-Shell-Variables.html#Special-Shell-Variables and this update to the documentation source, detailing even more inconsistencies: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=10d26aa - -- 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 iEYEARECAAYFAkln/YgACgkQ84KuGfSFAYAiHQCfXdr95aIJvrb7NzunhvYDgEiU fyQAnj2yJ/gkRLRrvWJeqAOR1CnDKflj =NtxW -END PGP SIGNATURE-