Re: Why escape char `:' with `\' when auto completing filenames?

On 17 Feb 2011, at 23:02, Chet Ramey wrote: > >>> >>> "Clark J. Wang" writes: >>> I think char `:' is not special in bash. >>> >>> $ printf "%q\n" "$COMP_WORDBREAKS" >>> $' \t\n"\'><=;|&(:' >>> >>> >> I don't think that explain the issue. > >

Re: Why escape char `:' with `\' when auto completing filenames?

Maarten Billemont writes: > Why are we escaping all word break characters? rm file:name and rm file\:name > are effectively identical, I'm not sure I see the need for escaping it. How do you differentiate between completing file:name and completing file:name? Andreas. -- Andreas Schwab, sch.

Re: Why escape char `:' with `\' when auto completing filenames?

On Fri, Feb 18, 2011 at 5:38 PM, Andreas Schwab wrote: > Maarten Billemont writes: > > > Why are we escaping all word break characters? rm file:name and rm > file\:name are effectively identical, I'm not sure I see the need for > escaping it. > > How do you differentiate between completing file:n

Re: Why escape char `:' with `\' when auto completing filenames?

"Clark J. Wang" writes: > On Fri, Feb 18, 2011 at 5:38 PM, Andreas Schwab wrote: > >> Maarten Billemont writes: >> >> > Why are we escaping all word break characters? rm file:name and rm >> file\:name are effectively identical, I'm not sure I see the need for >> escaping it. >> >> How do you dif

Re: Why escape char `:' with `\' when auto completing filenames?

On Fri, Feb 18, 2011 at 6:36 PM, Andreas Schwab wrote: > "Clark J. Wang" writes: > > > On Fri, Feb 18, 2011 at 5:38 PM, Andreas Schwab >wrote: > > > >> Maarten Billemont writes: > >> > >> > Why are we escaping all word break characters? rm file:name and rm > >> file\:name are effectively identi

Re: Why escape char `:' with `\' when auto completing filenames?

On Fri, Feb 18, 2011 at 12:17 PM, Clark J. Wang wrote: > On Fri, Feb 18, 2011 at 5:38 PM, Andreas Schwab >wrote: > > > Maarten Billemont writes: > > > > > Why are we escaping all word break characters? rm file:name and rm > > file\:name are effectively identical, I'm not sure I see the need for

Re: Why escape char `:' with `\' when auto completing filenames?

"Clark J. Wang" writes: > On Fri, Feb 18, 2011 at 6:36 PM, Andreas Schwab wrote: > >> "Clark J. Wang" writes: >> >> > On Fri, Feb 18, 2011 at 5:38 PM, Andreas Schwab > >wrote: >> > >> >> Maarten Billemont writes: >> >> >> >> > Why are we escaping all word break characters? rm file:name and rm >

Re: [bash 4.2] `declare -g' bug?

On 2/17/11 10:25 PM, Clark J. Wang wrote: > On Fri, Feb 18, 2011 at 8:45 AM, Chet Ramey > wrote: > > > The -g option exists solely to create variables at the global scope. The > intent is that functions be able to declare global variables with > attribute

Re: Why escape char `:' with `\' when auto completing filenames?

On Fri, Feb 18, 2011 at 6:21 PM, Clark J. Wang wrote: > On Fri, Feb 18, 2011 at 6:02 AM, Chet Ramey wrote: > >> >> For pete's sake. If you don't think they should be word break characters, >> modify the value of COMP_WORDBREAKS. For the record, @ causes a word >> break >> so you can complete h

Re: Why escape char `:' with `\' when auto completing filenames?

On Fri, Feb 18, 2011 at 6:48 PM, Pierre Gaston wrote: > > > On Fri, Feb 18, 2011 at 12:17 PM, Clark J. Wang wrote: > >> On Fri, Feb 18, 2011 at 5:38 PM, Andreas Schwab > >wrote: >> >> > Maarten Billemont writes: >> > >> > > Why are we escaping all word break characters? rm file:name and rm >> > f

Re: Inconsistence when checking if a pattern is quoted or not for `==' and `=~' in [[ ]]

On Thu, Feb 17, 2011 at 05:18:23PM -0500, Chet Ramey wrote: > Maybe if the man page had read "...to force the quoted portion to be > matched as a string" this could have been avoided. I like this answer. Removing ambiguity ("it" could refer to the whole pattern or to the quoted portion) is always

Re: [bash 4.2] `declare -g' bug?

On Fri, Feb 18, 2011 at 11:25:48AM +0800, Clark J. Wang wrote: > A global var can always be declared out of a func (usually at the beginning > of the script) so what's the main intention of introducing a new `-g' > option? The main reason, as I understand it, is so that you can declare an associat

Re: [bash 4.2] `declare -g' bug?

On Fri, Feb 18, 2011 at 9:35 PM, Greg Wooledge wrote: > On Fri, Feb 18, 2011 at 11:25:48AM +0800, Clark J. Wang wrote: > > A global var can always be declared out of a func (usually at the > beginning > > of the script) so what's the main intention of introducing a new `-g' > > option? > > The ma

Re: Inconsistence when checking if a pattern is quoted or not for `==' and `=~' in [[ ]]

On Fri, Feb 18, 2011 at 9:10 PM, Greg Wooledge wrote: > On Thu, Feb 17, 2011 at 05:18:23PM -0500, Chet Ramey wrote: > > Maybe if the man page had read "...to force the quoted portion to be > > matched as a string" this could have been avoided. > > I like this answer. Removing ambiguity ("it" cou

Re: typeset -r prevents local variable of same name.

On 2/17/11 10:23 PM, Eric Blake wrote: > On 02/17/2011 08:18 PM, Chet Ramey wrote: >> On 2/17/11 10:12 PM, Eric Blake wrote: >>> On 02/17/2011 07:48 PM, Chet Ramey wrote: Consider a quick, contrived example: an administrator writes a shell package (library, set of functions, whatever) tha

Brace expansion inside of command substitution - broken or is it me?

Hi all, I stumbled upon some rather strange behaviour that I just can't explain. Hopefully one of you can help me with that. :) Let's start with a simple brace expansion: $ echo {1..3} 1 2 3 Now add some quotes to prevent that expansion: $ echo "{1..3}" {1..3} Adding command substitution:

Re: Brace expansion inside of command substitution - broken or is it me?

On Fri, Feb 18, 2011 at 10:32:13PM +0100, Peter Hofmann wrote: > > $ echo "$(echo "{1..3}")" > 1 2 3 > > Huh? Brace expansion is a funny thing. My belief at the moment -- I'm sure someone will correct me if I'm wrong -- is that because you've got everything quoted up, it's all seen as one "wo

Re: Brace expansion inside of command substitution - broken or is it me?

Greg Wooledge writes: > On Fri, Feb 18, 2011 at 10:32:13PM +0100, Peter Hofmann wrote: >> >> $ echo "$(echo "{1..3}")" >> 1 2 3 >> >> Huh? > > Brace expansion is a funny thing. My belief at the moment -- I'm sure > someone will correct me if I'm wrong -- is that because you've got > everythi

Re: Brace expansion inside of command substitution - broken or is it me?

On Fri, Feb 18, 2011 at 10:53:31PM +0100, Andreas Schwab wrote: > Greg Wooledge writes: > > > On Fri, Feb 18, 2011 at 10:32:13PM +0100, Peter Hofmann wrote: > >> > >> $ echo "$(echo "{1..3}")" > >> 1 2 3 > >> > >> Huh? > > > > Brace expansion is a funny thing. My belief at the moment -- I'm

Re: Brace expansion inside of command substitution - broken or is it me?

On 2/18/11 4:32 PM, Peter Hofmann wrote: > So far, so good. It's what I expected. Let's add another level of > quotes: > > $ echo "$(echo "{1..3}")" > 1 2 3 > > Huh? Actually, I was expecting to get the same output as before. > > Some debug output: > > $ set -x > $ echo "$(echo "{1..3}")"

empty quotes break pattern replacements in bash-4.2

this simple code no longer works in bash-4.2: $ f=abc; echo ${f##""a} abc same goes for ${f//""a} and ${f%%""c}, and perhaps more operations removing the quotes, or quoting the single char in question, makes it work: $ f=abc; echo ${f##a} ${f##"a"} bc bc the original bug report uses variables in

Re: empty quotes break pattern replacements in bash-4.2

On 2/18/11 9:06 PM, Mike Frysinger wrote: > this simple code no longer works in bash-4.2: > $ f=abc; echo ${f##""a} > abc > same goes for ${f//""a} and ${f%%""c}, and perhaps more operations One more: everything that calls getpattern(). > removing the quotes, or quoting the single char in questio

Re: [bash4.2] ${v//[/} bug?

On 2/15/11 10:16 PM, Clark J. Wang wrote: > On Wed, Feb 16, 2011 at 9:59 AM, Chet Ramey > wrote: > > On 2/15/11 6:18 AM, Clark J. Wang wrote: > > For following script: > > > > var='[hello' > > echo "${var//[/}" > > > > With bash 4.1 it outpu

Re: empty quotes break pattern replacements in bash-4.2

On Friday, February 18, 2011 23:17:11 Chet Ramey wrote: > On 2/18/11 9:06 PM, Mike Frysinger wrote: > > this simple code no longer works in bash-4.2: > > $ f=abc; echo ${f##""a} > > abc > > same goes for ${f//""a} and ${f%%""c}, and perhaps more operations > > One more: everything that calls getpa