Re: Degenerate case in brace expansion.

2025-03-08 Thread Lawrence Velázquez
On Sat, Mar 8, 2025, at 3:05 PM, Kaz Kylheku wrote:
>
>   $ echo {a..{z,y}}
>   a..z a..y
>
> Is this documented? I would expect it to produce
>
>   {a..z} {a..y}

This is fixed in the devel branch:

$ git -C ~/src/bash checkout -q c3ca11424d2ae66cafa2f931b008dfb728e209a5
$ { ~/src/bash/configure && make; } >/dev/null 2>&1; echo "$?"
0
$ ./bash -c 'echo {a..{z,y}}'
{a..z} {a..y}

https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=c3ca11424d2ae66cafa2f931b008dfb728e209a5

-- 
vq



Re: Possible bug for nested curly brace expansion

2025-03-08 Thread microsuxx
{0} is no expansion
{0,} is
it must be 2+

On Thu, Mar 6, 2025, 7:40 PM Trond Endrestøl via Bug reports for the GNU
Bourne Again SHell  wrote:

> $ bash --version
> GNU bash, version 5.2.37(0)-release (amd64-portbld-freebsd14.1)
> Copyright (C) 2022 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
>
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> $ echo devel/llvm{1{1,2,3,4,5,6,7,8,9},2{0}}
> devel/llvm11 devel/llvm12 devel/llvm13 devel/llvm14 devel/llvm15
> devel/llvm16 devel/llvm17 devel/llvm18 devel/llvm19 devel/llvm2{0}
>
> $ echo devel/llvm{1{1,2,3,4,5,6,7,8,9},2{0,1}}
> devel/llvm11 devel/llvm12 devel/llvm13 devel/llvm14 devel/llvm15
> devel/llvm16 devel/llvm17 devel/llvm18 devel/llvm19 devel/llvm20
> devel/llvm21
>
> I didn't expect the curly braces at the end of the first example. It
> should produce devel/llvm20 in my opinion. Everything is fine as long
> as the number of elements are > 1.
>
> csh(1) in FreeBSD gives the expected expansion for both examples:
>
> $ echo devel/llvm{1{1,2,3,4,5,6,7,8,9},2{0}}
> devel/llvm11 devel/llvm12 devel/llvm13 devel/llvm14 devel/llvm15
> devel/llvm16 devel/llvm17 devel/llvm18 devel/llvm19 devel/llvm20
>
> $ echo devel/llvm{1{1,2,3,4,5,6,7,8,9},2{0,1}}
> devel/llvm11 devel/llvm12 devel/llvm13 devel/llvm14 devel/llvm15
> devel/llvm16 devel/llvm17 devel/llvm18 devel/llvm19 devel/llvm20
> devel/llvm21
>
> --
> --
> Trond Endrestøl   |   trond.endres...@ximalas.info
> Member of ACM, NAS, NUUG  |   FreeBSD 14.2-S & Alpine 2.26
>


Degenerate case in brace expansion.

2025-03-08 Thread Kaz Kylheku
Hi all, 

  $ echo {a..zz}
  {a..zz} 

Right; the sequence is not well-formed according, and so this is not brace
syntax; the syntax stays intact as verbatim text, braces and all.

But:

  $ echo {a..{z,y}}
  a..z a..y

Is this documented? I would expect it to produce

  {a..z} {a..y}

on the hypothesis that the outer brace is not well-formed, and
therefore literal, but the inner brace is active, like any
valid brace in the middle of literal text. I.e. we have
"alpha{brace}omega", where alpha is "{a.."  and omega is "}".

If we strip the braces, that means we have recognized the syntax
for special processing, but then it is not evident in the
a..z a..y output how it relates to sequence expansion.

I came across this because the recent discussion in this list prompted
me to go looking into my own brace expansion implementation, which
I recently extended into supporting sequences.

It has the expected behavior:

  1> (sys:brace-expand "{a..{z,y}}")
  ("{a..z}" "{a..y}")

I was just "comparing notes" on some exotic cases like this against
Bash, and noticed this.

(An interesting way to treat this case would be to allow the inner
element expansion to produce multiple sequence expansions,
which are then processed; i.e. as if we took the resulting
{a..z} and {a..y} shown in my implementation, and then "activated"
the braces.)

Cheers ...