dynamic-complete-history documentation change

2005-09-12 Thread Michael Wardle

Hi

It seems that the binding for Alt-Tab changed from dynamic-complate-history 
to tab-insert around Bash 3.0.


The bashref.info file as found in Debian and the current version 3.0 Bash 
source tarball on http://ftp.gnu.org/gnu/bash/ both still state the default 
binding for dynamic-complete-history is Alt-Tab.


It looks like this section of the Bash Reference Manual is generated from 
the file rluser.texi, which is provided by Readline.  The current version on 
the web no longer mentions dynamic-complete-history.

http://cnswww.cns.cwru.edu/~chet/readline/readline.html#SEC19

Could you please regenerate the file bashref.info in the upstream sources 
and/or update the Readline documentation if you get the time.


Thanks


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash


ksh style [[ conditional does not match patterns

2005-12-08 Thread Michael Wardle
In the SHELL GRAMMAR section of the bash man page, the [[ expression ]] 
syntax is described:


	When the == and != operators are used, the string to the right of the 
operator is

considered a pattern and matched according to the rules described below
under Pattern Matching.

The Pattern Matching subsection describes the familiar file name 
globbing syntax:


*  Matches any string, including the null string.
?  Matches any single character.
etc.

Yet when I attempt a simple match, it doesn't work:

bash-3.00$ [[ "foo" == "foo" ]]
bash-3.00$ echo $?
0
bash-3.00$ [[ "foo" == "fo?" ]]
bash-3.00$ echo $?
1

(I expect the second command to return 0 exit status as well, since the 
question mark should match the single "o" character at position 3 in "foo".)


Am I doing something wrong?


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash


Re: nullglob option breaks complex parameter expansion/deletion

2005-07-02 Thread Michael Wardle
Hi Chet

Thanks for your very prompt reply.

I understand that globbing is happening, but I don't understand why
deleting a parameter should occur with nullglob set if the parameter
matches but the word to delete doesn't.  The bash behavior seems to make
this construct useful only for file name deletion if nullglob is set,
when it seems to be useful for any substring deletion if nullglob is
unset.

I also noticed in the POSIX standard that quoting the word part should
cause it to be literal and prevent globbing.  If I try this in bash, I
get the same result as in my original message, that is:

$ shopt -s nullglob
$ connectioninfo='${HOST%%".*"} ${USER}'
$ echo $connectioninfo
${USER}

I think $connectioninfo should remain unchanged due to the word being
quoted, and wonder if bash supports this quoting syntax.




___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash


Re: nullglob option breaks complex parameter expansion/deletion

2005-07-02 Thread Michael Wardle
> I also noticed in the POSIX standard that quoting the word part should
> cause it to be literal and prevent globbing.  If I try this in bash, I
> get the same result as in my original message, that is:
> 
> $ shopt -s nullglob
> $ connectioninfo='${HOST%%".*"} ${USER}'
> $ echo $connectioninfo
> ${USER}

Actually, this seems similar to the following:

$ shopt -s nullglob
$ echo $USER
michael
$ var='${USER}".*"'
$ typeset -p var
declare -- var="\${USER}\".*\""
$ echo $var

$ echo "$var"
${USER}".*"
$ eval echo "$var"
michael.*

It looks like a bare $var is being expanded multiple times in a way that
I don't understand, but perhaps that is just the nature of shell.




___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash


Re: nullglob option breaks complex parameter expansion/deletion

2005-07-02 Thread Michael Wardle
On Sat, 2005-07-02 at 12:24 -0400, Chet Ramey wrote:
> Michael Wardle wrote:
> > Hi Chet
> > 
> > Thanks for your very prompt reply.
> > 
> > I understand that globbing is happening, but I don't understand why
> > deleting a parameter should occur with nullglob set if the parameter
> > matches but the word to delete doesn't.  The bash behavior seems to make
> > this construct useful only for file name deletion if nullglob is set,
> > when it seems to be useful for any substring deletion if nullglob is
> > unset.
> 
> The word in question is *not* being parameter expanded.  It is the
> result of a *different* parameter expansion:  the unquoted expansion
> of $connectioninfo.

I wasn't saying that the right-hand side was being parameter expanded.
I was trying to use the wording in the POSIX standard, which states:
"The word shall be expanded to produce a pattern."  I think this is
supposed to refer to file name expansion (globbing), but I confess to
being confused by this wording myself.

> Since the results of the parameter expansion of $connectioninfo are
> subject to filename expansion, the unquoted `*' in that word is run
> through *normal filename expansion*.  Since that expansion looks only
> for filenames and, since nullglob is set, deletes words containing
> globbing operators that don't match filenames, the word ends up being
> removed.

I understand that normal file name expansion is occurring, but I can't
see any use for it in this construct.  I would be happy to learn of such
a use, but in the absence of one, I would advocate the parameter
deletions such as ${parameter%word} be a special case not subject to
nullglob.

> You might get a clearer picture of what's happening if you ran
> 
>   echo "$connectioninfo"
> 
> and inhibited the filename expansion that normally takes place.

I believe my followup exhibited this understanding.

> > I also noticed in the POSIX standard that quoting the word part should
> > cause it to be literal and prevent globbing.  If I try this in bash, I
> > get the same result as in my original message, that is:
> 
> You have misunderstood which expansion needs to be quoted.  It's the
> expansion of $connectioninfo that needs quoting, as above.

POSIX says this:
${x#"*"}
The literal asterisk is quoted and not special.

Which leads me to believe that quoting the asterisk should have the
desired result, and certainly at least a different result from that
which I am seeing.

Again, I don't understand why nullglob is useful inside ${parameter%%
word}, and it's certainly not obvious why quoting the right-hand side
should be necessary.




___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash


Re: nullglob option breaks complex parameter expansion/deletion

2005-07-05 Thread Michael Wardle
I've come to a better understanding of how expansion occurs and now 
realize that this is not a bug.


Thanks to Chet for his time in responding to my messages.


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash