On 16 Jan 2012, at 11:29 AM, Chet Ramey wrote:
> I think you've uncovered a potential problem, but not the one you
> think. The important thing is that `>' is not a command separator and
> cannot be a command name. As such, it kind of slips between the cracks
> of the completion system.
> > Of co
On 1/16/12 2:14 PM, Greg Wooledge wrote:
> Someone in IRC was doing an overly complex command invovling grep "^.{1,8}"
> inside a command substitution, and we believe he stumbled upon a bash bug.
> I've simplified it down to this:
>
> $ echo "$(echo "a{1,8}")"
> a1 a8
>
> The curly braces here sh
Someone in IRC was doing an overly complex command invovling grep "^.{1,8}"
inside a command substitution, and we believe he stumbled upon a bash bug.
I've simplified it down to this:
$ echo "$(echo "a{1,8}")"
a1 a8
The curly braces here should not be treated as a brace expansion, since
they're o
On 1/14/12 12:49 AM, Linda Walsh wrote:
> /* vim: ts=1 sw=1 et sc fo=cqwa1 tw=78 syntax=css */
> There's actually 1 parts 2 this, I ran into the 2nd while testing the
> first...
Like Greg Wooledge, I wasn't able to reproduce the second issue with
`read -N 1' (which I assume is actually something
On 1/11/12 3:31 AM, Sung Pae wrote:
> Hello,
>
> There is a small bug in the default completion system due to a
> disagreement between a few functions in what is considered a command
> delimiter. I have tested this on the current devel HEAD in the git repo
> (d00a2d6).
I think you've uncovered a
On Fri, Jan 13, 2012 at 09:49:56PM -0800, Linda Walsh wrote:
> BASH_VERSION = 4.1.10(1)-release
> I wanted to be able to check the keyboard if the user had 'typed' ahead,
read -t 0
> I wanted to do a
> read -t 0.01 pre_ans
>
> just before my read to see if there was input already available a
