Re: Brace expansion ordering vs. parameter expansion
On 4/29/21 12:59 PM, Tom (AST) Watson wrote:
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
This one doesn't, but putting in the slash skips the first brace
expansion entirely, instead of relying on the degenerate brace expansion
to be left unchanged, so it's safer in general.
--
``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/
RE: Re: Brace expansion ordering vs. parameter expansion
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/
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 (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/
Re: Brace expansion ordering vs. parameter expansion
On Thu, Apr 29, 2021 at 03:12:09PM +0300, Ilkka Virta wrote: > 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 (of course they tell the "what", but not the > "why"). I didn't dig through all the mailing lists, though. I don't know the reason, other than what Chet said earlier in this thread (that it was never designed to work that way). > Of course there's other ways with subshells, temporary arrays and using > e.g. seq (but I'm not sure that exists on all systems either). seq(1) is not standard, and definitely does *not* exist on all systems. Some have jot(1) instead, but many commercial Unixes have neither.
Brace expansion ordering vs. parameter expansion
On Thu, Apr 29, 2021 at 4:18 AM Chet Ramey 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 (of course they tell the "what", but not the
"why"). I didn't dig through all the mailing lists, though.
The versions of ksh I have seem to do braces after parameter expansions
(even interpreting unquoted braces that come from expansions), so
$ ksh -c 'a=3 b=5; echo {$a..$b}'
3 4 5
$ ksh -c 'brace="{3..5}"; echo $brace'
3 4 5
The braces-then-variables order also comes up somewhat often on
unix.stackexchange, with people trying the {$a..$b} and being baffled it
doesn't work. The Bash behaviour allows doing $v{a,b} to expand $va and $vb
instead, but that doesn't seem too useful, can't be used to expand the
variables quoted, and would probably be more of a use case for associative
arrays anyway.
In the simple case above, using 'eval' of course works, but it starts
getting problematic if there's a more complex command line, with variables
that should _not_ run through all expansions again. E.g.
somecommand "$foo" {1..$i}
would require something like
eval somecommand '"$foo"' \{1..$i}
with extra quotes or backslashes added to any expansions and quotes on the
command line.
For a loop over some range of numerical values there is always for (( ...
)), but for x in {$i..$j} would be shorter and would work with something
like for x in foo{$i..$j} without an extra step of gluing the strings
together inside the loop.
Of course there's other ways with subshells, temporary arrays and using
e.g. seq (but I'm not sure that exists on all systems either).
