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-
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: ${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
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: 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: 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/
