RE: Re: Brace expansion ordering vs. parameter expansion

2021-04-29 Thread Tom (AST) Watson
All...

I've resigned to having it the way it is, but I note that the solution doesn't 
need the backslash escape:
[tsw@box6 ~]$ k=10
[tsw@box6 ~]$ eval echo {1..$k}
1 2 3 4 5 6 7 8 9 10

I'm finding out lots of things as I go along.  Need to understand the 
"features" as they show themselves.

Thanks for the input.  It has been helpful.

...Tom
-Original Message-
From: Chet Ramey  
Sent: Thursday, April 29, 2021 07:46
To: Ilkka Virta 
Cc: chet.ra...@case.edu; Tom (AST) Watson ; 
bug-bash@gnu.org
Subject: [External] Re: Brace expansion ordering vs. parameter expansion

On 4/29/21 8:12 AM, Ilkka Virta wrote:

> Maybe, but it's never worked that way and was never intended to. You can
> get what you need using eval:
> 
> eval echo \{1..${i}}
> 
> 
> BTW, was there some background to why they're ordered like this? I'm 
> not sure if I have heard the story, and didn't see anything about it 
> in Greg's wiki or bash-hackers.org <http://bash-hackers.org> (of 
> course they tell the "what", but not the "why"). I didn't dig through all the 
> mailing lists, though.

Here's something I wrote in response to another message:

=
OK. Bash has had brace expansion in essentially its current form since 1991, 
and we chose the implementation we did with an eye towards making the code 
something that other applications could just pick up and incorporate. Korn 
chose to perform brace expansion as a component of filename expansion 
(globbing), which happens after the other word expansions. I'm sure he thought 
it was better, but he chose not to be compatible with bash.
=

I wrote 1991, but it was actually early 1989 when we (Brian and I) wrote the 
brace expansion code and put it in. We decided early on to make brace expansion 
independent of filename expansion, so you could have brace expansion even after 
performing `set -f'. There was thought towards making the brace expansion code 
reusable, in the sense that other GNU tools could take the code and easily add 
it to their argument processing. We were also reluctant to change the filename 
expansion code, which, at the time, we shared with other GNU applications 
including emacs.

So we made brace expansion a separate step, one that could be enabled and 
disabled independent of other expansions, with a defined input and output 
format, and made it happen before the POSIX word expansions. And here we are, 
thirty-plus years later.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/


Problem with sequences with variables?

2021-04-28 Thread Tom (AST) Watson
Hi...

I was trying to do some sequences, and it looks like they don't like variables. 
 See the following:
[user@box3 ~]$ echo $BASH_VERSION
5.0.17(1)-release
[user@box3 ~]$ echo {1..10}
1 2 3 4 5 6 7 8 9 10
[user@box3 ~]$ echo $l
10
[user@box3 ~]$ echo {1..${l}}
{1..10}
[user@box3 ~]$

Shouldn't the second sequence echo be the same as the first sequence echo?  It 
would be MUCH more useful if it were.

Of course, this could be just a feature, I don't really know.  This is running 
on a Fedora 31 release build if that makes a difference.

Thanks,
...Tom Watson

More info:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions 
-fstack-protector-strong -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-Wno-parentheses -Wno-format-security
uname output: Linux box3.appsig.com 5.7.7-100.fc31.x86_64 #1 SMP Wed Jul 1 
20:37:05 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 5.0
Patch Level: 17
Release Status: release

--
Tom Watson  (I'm at work now)
thomas.3.wat...@rtx.com