On 10/9/23 1:18 PM, Ti Strga wrote:
The bug likely got checked in earlier than 5.2.15, that's just what I
happened to be running when I ran into this.
Thanks, it's already been fixed in the devel branch.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ar
The bug likely got checked in earlier than 5.2.15, that's just what I
happened to be running when I ran into this.
$ declare -p BASH_VERSINFO
declare -ar BASH_VERSINFO=([0]="5" [1]="2" [2]="15" [3]="3"
[4]="release" [5]="x86_64-pc-cygwin")
$ bashbug
/usr/bin/bashbug: line 135: [: missing `]'
/usr
Jan Schampera wrote:
> I intentionally expected <() and >() to be as protected as $() is. Is
> there a specific reason for them to not be protected against the
> initial parsing?
Those sequences are not treated specially, but it's a reasonable
suggestion for a future enhancement.
Chet
--
``Th
On Thu, 2 Aug 2007 09:29:19 -0400
Chet Ramey <[EMAIL PROTECTED]> wrote:
> > Here was an interesting bug which was some what unexpected.
> >
> > cat <(find ./ -iname t{1,2,3})
> >
> > this is a valid command according to bash due to a bugged expansion
> > of {1,2,3} and the process expansion. It
> Here was an interesting bug which was some what unexpected.
>
> cat <(find ./ -iname t{1,2,3})
>
> this is a valid command according to bash due to a bugged expansion of
> {1,2,3} and the process expansion. It becomes three commands:
>
> find ./ -iname t1
> find ./ -iname t2
> find ./ -iname
Here was an interesting bug which was some what unexpected.
cat <(find ./ -iname t{1,2,3})
this is a valid command according to bash due to a bugged expansion of
{1,2,3} and the process expansion. It becomes three commands:
find ./ -iname t1
find ./ -iname t2
find ./ -iname t3
but as we know
