On 3/15/21 8:12 PM, Chet Ramey wrote:
I'm kicking around a change to associative array subscript expansion that
would basically force the equivalent of `assoc_expand_once' on all the
time, with additional changes to prevent unwanted double expansion in an
arithmetic expression context. The
2021年4月19日(月) 7:01 Chet Ramey :
> On 4/16/21 12:11 PM, Koichi Murase wrote:
> >> nobody should be surprised to see a `double expansion'.
> >
> > In that case, I agree that no one would be surprised by the double
> > expansion of the *variable names* because it's the purpose of the
> > namerefs.
2021年4月19日(月) 6:46 Chet Ramey :
> On 4/13/21 5:18 AM, Koichi Murase wrote:
> > I actually doubt whether there are real use cases for the behavior
> > that «iref=a[@]; ${!iref}» or «declare -n nref=a[@]; $nref» expands to
> > all the elements of *associative* arrays. Maybe it is useful to
> >
On Mon, Apr 19, 2021 at 6:01 AM Chet Ramey wrote:
> > Yes, but if `unset' is defaulted to `assoc_expand_once' behavior while
> > indirect expansions and namerefs aren't changed, users still need to
> > do two different ways of quoting: « unset "a[$key]" » versus «on
> > iref='a[$key]'; echo
On 4/16/21 12:11 PM, Koichi Murase wrote:
From the users' point of view, indirect expansions and name references
currently undergo "double expansions" in assigning time and in
reference time; I mean naive users will write as « iref=a[$key] »
instead of « iref='a[$key]' » and run « echo
On 4/13/21 5:18 AM, Koichi Murase wrote:
I actually doubt whether there are real use cases for the behavior
that «iref=a[@]; ${!iref}» or «declare -n nref=a[@]; $nref» expands to
all the elements of *associative* arrays. Maybe it is useful to
expand the indexed arrays in this way because
2021年4月16日(金) 1:04 Chet Ramey :
> On 4/13/21 11:11 PM, Koichi Murase wrote:
> > 2021年4月14日(水) 0:24 Chet Ramey :
> >> On 4/13/21 5:01 AM, Koichi Murase wrote:
> >>> But I expected some design consideration enabling a[$key] for an
> >>> arbitrary key in the indirect expansions and namerefs.
> >>
>
On Fri, Apr 16, 2021 at 12:10 AM Chet Ramey wrote:
> > I actually agree with konsolebox that assoc_expand_once for unset
> > shouldn't be defaulted. The option `assoc_expand_once' is incomplete
> > in the sense that the behavior of `a[@]' and `a[*]' are subtle. I see
> > the current default
On 4/13/21 11:11 PM, Koichi Murase wrote:
2021年4月14日(水) 0:24 Chet Ramey :
On 4/13/21 5:01 AM, Koichi Murase wrote:
But I expected some design consideration enabling a[$key] for an
arbitrary key in the indirect expansions and namerefs.
Why? Why should the shell carry around (and expect the
> But, If `assoc_expand_once' is needed
> to make the behavior more friendly to naive users, I think we should
> also take care of naive users who write « iref='a[$key]'; echo
> ${!iref} ».
Sorry, typo of "naive users who write « iref=a[$key]; echo ${!iref} »".
2021年4月14日(水) 0:24 Chet Ramey :
> On 4/13/21 5:01 AM, Koichi Murase wrote:
> > But I expected some design consideration enabling a[$key] for an
> > arbitrary key in the indirect expansions and namerefs.
>
> Why? Why should the shell carry around (and expect the user to remember)
> information
On 4/13/21 6:36 PM, L A Walsh wrote:
So echo ${a[@]} = expansion of all, but
unset a[@] would only delete 1 element w/key '@'
how do I echo 1 element with key '@'
Creating arbitrary definitions of behavior for the similar syntax
seems like a sign of random feature-ism.
The
On Wed, Apr 14, 2021 at 6:37 AM L A Walsh wrote:
> So echo ${a[@]} = expansion of all, but
> unset a[@] would only delete 1 element w/key '@'
> how do I echo 1 element with key '@'
Indeed we can only quote:
a['@']=1234
echo "${a['@']}"
unset "a['@']"
Or have it interpreted as a value
On 2021/04/06 08:52, Greg Wooledge wrote:
In that case, I have no qualms about proposing that unset 'a[@]' and
unset 'a[*]' be changed to remove only the array element whose key is
'@' or '*', respectively, and screw backward compatibility. The current
behavior is pointless and is nothing but a
On 4/13/21 5:01 AM, Koichi Murase wrote:
2021年4月13日(火) 0:16 Chet Ramey :
On 4/6/21 12:46 PM, Koichi Murase wrote:
Looking at another thread
https://lists.gnu.org/archive/html/bug-bash/2021-04/threads.html#00051,
I'm now also interested in how we can handle the indirect expansions
for 'a[@]'
2021年4月13日(火) 18:01 Koichi Murase :
> 2021年4月13日(火) 0:16 Chet Ramey :
> > On 4/6/21 12:46 PM, Koichi Murase wrote:
> > > Looking at another thread
> > > https://lists.gnu.org/archive/html/bug-bash/2021-04/threads.html#00051,
> > > I'm now also interested in how we can handle the indirect
2021年4月13日(火) 0:16 Chet Ramey :
> On 4/6/21 12:46 PM, Koichi Murase wrote:
> > Looking at another thread
> > https://lists.gnu.org/archive/html/bug-bash/2021-04/threads.html#00051,
> > I'm now also interested in how we can handle the indirect expansions
> > for 'a[@]' and the namerefs for 'a[@]':
On 4/9/21 12:20 PM, Koichi Murase wrote:
That said, the fact that you can put 'a[@]' in an indirect variable and
get an array expansion out of "${!x}" is completely repulsive to me.
Currently, we need to write as «iref='a[$key]'; echo "${!iref}"» so
that $key is not expanded until the
On 4/6/21 12:46 PM, Koichi Murase wrote:
Looking at another thread
https://lists.gnu.org/archive/html/bug-bash/2021-04/threads.html#00051,
I'm now also interested in how we can handle the indirect expansions
for 'a[@]' and the namerefs for 'a[@]':
$ declare -A a=(['@']=x [1]=y)
$
$ # indirect
On 4/6/21 12:46 PM, Koichi Murase wrote:
How about the cases with `test -v a[@]' and `key=@; test -v a[$key]'?
By the time test sees its arguments, there is no difference between these
two cases. You can do things to differentiate when running the `[['
command, but `test' goes through the
On Fri, Apr 9, 2021 at 8:17 PM Greg Wooledge wrote:
> How can you look at that code and call it anything other than a hack?
> It's a piece of pure desperation. You can only READ the array, not write
> to it. You can't do an index iteration, either -- only a value iteration.
> And you still have
.2021年4月9日(金) 23:53 Chet Ramey :
> On 4/8/21 6:23 PM, Koichi Murase wrote:
> > I currently don't have any better idea, but in that way, it seems to
> > me that there is no way to represent a reference to an element
> > associated with key=@ under the new `assoc_expand_once', which was
> > what I
On 4/8/21 6:23 PM, Koichi Murase wrote:
I currently don't have any better idea, but in that way, it seems to
me that there is no way to represent a reference to an element
associated with key=@ under the new `assoc_expand_once', which was
what I wanted to argue in my previous reply.
Under
On Fri, Apr 09, 2021 at 08:17:52AM +0800, konsolebox wrote:
> On Fri, Apr 9, 2021 at 4:08 AM Greg Wooledge wrote:
> > But apparently someone stumbled upon this trick, and passed it around,
> > and now there's a whole subculture of people who use this as a hack for
> > trying to pass array
On Fri, Apr 9, 2021 at 8:17 AM konsolebox wrote:
> It's a definite shell feature despite lacking internal sanity checks.
*despite having limited
--
konsolebox
On Fri, Apr 9, 2021 at 4:08 AM Greg Wooledge wrote:
> But apparently someone stumbled upon this trick, and passed it around,
> and now there's a whole subculture of people who use this as a hack for
> trying to pass array variables to functions by reference. (This hack
> predates declare -n.)
On Fri, Apr 9, 2021 at 3:21 AM Chet Ramey wrote:
>
> On 4/6/21 11:42 AM, konsolebox wrote:
>
> > Or maybe just completely avoid this new behaviors and allow another
> > way to unset an element of an array.
> >
> > a[$key]=()
> > a[@]=()
>
> While this is mildly interesting syntax, and currently
On Fri, Apr 9, 2021 at 2:19 AM Chet Ramey wrote:
> What is your end goal? To run the same script on different versions of
> bash, or something else?
Nevermind. I overthinked.
--
konsolebox
2021年4月9日(金) 5:08 Greg Wooledge :
> On Thu, Apr 08, 2021 at 03:37:33PM -0400, Chet Ramey wrote:
> > On 4/6/21 1:42 PM, Greg Wooledge wrote:
> > > That said, the fact that you can put 'a[@]' in an indirect variable and
> > > get an array expansion out of "${!x}" is completely repulsive to me.
> >
>
On Thu, Apr 08, 2021 at 03:37:33PM -0400, Chet Ramey wrote:
> On 4/6/21 1:42 PM, Greg Wooledge wrote:
> > That said, the fact that you can put 'a[@]' in an indirect variable and
> > get an array expansion out of "${!x}" is completely repulsive to me.
>
> What do you think should happen?
What I
On 4/6/21 1:42 PM, Greg Wooledge wrote:
3) Expressions like a[$key] must be single-quoted in some contexts, or
you get surprising behaviors.
4) Expressions like a[$key] must be backslash-protected in some other
contexts, or you get surprising behaviors.
Yes, Greg, that's what we're
On 4/6/21 11:52 AM, Greg Wooledge wrote:
In that case, I have no qualms about proposing that unset 'a[@]' and
unset 'a[*]' be changed to remove only the array element whose key is
'@' or '*', respectively, and screw backward compatibility. The current
behavior is pointless and is nothing but a
On 4/6/21 11:42 AM, konsolebox wrote:
Or maybe just completely avoid this new behaviors and allow another
way to unset an element of an array.
a[$key]=()
a[@]=()
While this is mildly interesting syntax, and currently an error, I don't
think we need another new way to do this.
--
``The lyf
On 4/6/21 11:01 AM, Greg Wooledge wrote:
On Tue, Apr 06, 2021 at 11:28:13PM +0900, Koichi Murase wrote:
2) we
can distinguish the erasure of the element associated with key=@
`unset -v a[$key]' from the entire array erasure `unset -v a[@]'.
As a counter-proposal, Chet could entirely remove
On 4/6/21 10:28 AM, Koichi Murase wrote:
Thank you for the pointer. I still think changing the syntactic
treatment of the arguments of the `unset' builtin is the cleanest way
to solve the problem of `key=@; unset -v a[$key]'. Maybe we can ask
Chet why this isn't considered.
It's not
On 4/6/21 1:55 AM, Koichi Murase wrote:
2021年3月30日(火) 0:03 Chet Ramey :
On 3/15/21 9:41 PM, Koichi Murase wrote:
Can you also take care of the behavior of `unset -v 'a[@]''?
Well, you have to pick one behavior or another. The `@' subscript always
expands to all members of the array. The
On 4/5/21 6:49 PM, konsolebox wrote:
On Mon, Apr 5, 2021 at 9:44 PM Chet Ramey wrote:
On 4/1/21 3:02 PM, konsolebox wrote:
To do what, exactly?
To keep this working in both behaviors.
declare -A a
key='$(echo foo)'
a[$key]=1
unset 'a["$key"]'
declare -p a # declare -A a=()
I suppose.
On Tue, Apr 06, 2021 at 03:24:54PM -0500, Dennis Williamson wrote:
> Python 3.7 has insertion-order dictionaries. So these are dependable
> gerbils.
That explains my test results, which I didn't post. I had been told
in the past that python's dictionaries did NOT remember insertion
order, but
On Wed, Apr 7, 2021 at 4:09 AM Greg Wooledge wrote:
> There is no sorting in the output.
You're right. I misobserved the test I had before.
> (but not tcl's dictionaries,
> which are closer to what you're envisioning).
I don't know Tcl's dictionaries, but the clearest example I can give
is
On Tue, Apr 6, 2021, 3:09 PM Greg Wooledge wrote:
> On Wed, Apr 07, 2021 at 03:53:43AM +0800, konsolebox wrote:
> > Also if Bash could just store associative array
> > values as a list to preserve store order and stop expanding
> > "${array[@]}" based on the sorted order of the keys, then the
On Wed, Apr 07, 2021 at 03:53:43AM +0800, konsolebox wrote:
> Also if Bash could just store associative array
> values as a list to preserve store order and stop expanding
> "${array[@]}" based on the sorted order of the keys, then the slice
> function can also be applied there.
There is no
On Wed, Apr 7, 2021 at 12:20 AM Ilkka Virta wrote:
> What konsolebox said about a[$k]=() works in my Zsh for indexed arrays, but
> not associative ones.
> (It replaces an array slice, so can also be used to insert elements in the
> middle.)
Bash can adopt this. Also if Bash could just store
On Wed, Apr 07, 2021 at 01:46:27AM +0900, Koichi Murase wrote:
> I remember there was some discussion in the bug-bash list on the
> behavior of `test -v a[@]' which actually tests whether the array `a'
> has at least one element.
> It cannot be replaced by `test -v a' because
> `a' implies `a[0]'
2021年4月7日(水) 0:53 Greg Wooledge :
> On Tue, Apr 06, 2021 at 06:34:21PM +0300, Ilkka Virta wrote:
> > $ declare -A a=([foo]=123 [bar]=456)
> > $ unset 'a[@]'
> > $ declare -p a
> > bash: declare: a: not found
> >
> > i.e. both remove the whole array, not just the contents.
>
> Huh, so it does. I
On Tue, Apr 6, 2021 at 6:53 PM Greg Wooledge wrote:
> In that case, I have no qualms about proposing that unset 'a[@]' and
> unset 'a[*]' be changed to remove only the array element whose key is
> '@' or '*', respectively, and screw backward compatibility.
>
That also seems to be what Ksh and
On Tue, Apr 06, 2021 at 06:34:21PM +0300, Ilkka Virta wrote:
> $ declare -A a=([foo]=123 [bar]=456)
> $ unset 'a[@]'
> $ declare -p a
> bash: declare: a: not found
>
> i.e. both remove the whole array, not just the contents.
Huh, so it does. I didn't know that.
In that case, I have no qualms
On Tue, Apr 6, 2021 at 10:28 PM Koichi Murase wrote:
>
> 2021年4月6日(火) 21:06 Greg Wooledge :
> > On Tue, Apr 06, 2021 at 02:55:35PM +0900, Koichi Murase wrote:
> > > But, maybe we can introduce a special syntactic treatment of `unset'
> >
> > When I made a comment about the possibility of unset
On Tue, Apr 6, 2021 at 6:13 PM Greg Wooledge wrote:
> As a counter-proposal, Chet could entirely remove the special meaning
> of unset 'a[@]' and introduce a new option to unset which would take
> its place. It appears -a is not yet used, so that would be a good pick.
>
Unless I missed
On Tue, Apr 06, 2021 at 11:28:13PM +0900, Koichi Murase wrote:
> 2) we
> can distinguish the erasure of the element associated with key=@
> `unset -v a[$key]' from the entire array erasure `unset -v a[@]'.
As a counter-proposal, Chet could entirely remove the special meaning
of unset 'a[@]' and
2021年4月6日(火) 21:06 Greg Wooledge :
> On Tue, Apr 06, 2021 at 02:55:35PM +0900, Koichi Murase wrote:
> > But, maybe we can introduce a special syntactic treatment of `unset'
>
> When I made a comment about the possibility of unset becoming a keyword,
> Chet said he had no plans to do that.
>
> ...
On Tue, Apr 06, 2021 at 02:55:35PM +0900, Koichi Murase wrote:
> But, maybe we can introduce a special syntactic treatment of `unset'
When I made a comment about the possibility of unset becoming a keyword,
Chet said he had no plans to do that.
... here:
2021年3月30日(火) 0:03 Chet Ramey :
> On 3/15/21 9:41 PM, Koichi Murase wrote:
> > Can you also take care of the behavior of `unset -v 'a[@]''?
>
> Well, you have to pick one behavior or another. The `@' subscript always
> expands to all members of the array. The current behavior is consistent
> with
On Mon, Apr 5, 2021 at 9:44 PM Chet Ramey wrote:
>
> On 4/1/21 3:02 PM, konsolebox wrote:
>
> >> To do what, exactly?
> >
> > To keep this working in both behaviors.
> >
> > declare -A a
> > key='$(echo foo)'
> > a[$key]=1
> > unset 'a["$key"]'
> > declare -p a # declare -A a=()
>
> I suppose.
On 3/30/21 7:05 PM, konsolebox wrote:
As I've observed, in single expansion mode, unset will fail to unset a
value when the key has a closing bracket in it. Perhaps unset should
check the last character first when looking for the closing bracket.
Tested in 5.1.4.
There is some support for
On 4/1/21 3:02 PM, konsolebox wrote:
To do what, exactly?
To keep this working in both behaviors.
declare -A a
key='$(echo foo)'
a[$key]=1
unset 'a["$key"]'
declare -p a # declare -A a=()
I suppose. You'll be able to set compatibility levels to make this work
without resorting to wrappers.
On Fri, Apr 2, 2021 at 3:02 AM konsolebox wrote:
>
> On Fri, Apr 2, 2021 at 2:56 AM Chet Ramey wrote:
> >
> > On 4/1/21 2:55 PM, konsolebox wrote:
> >
> > > So to keep compatibility, would this be the right way?
> > >
> > > if [[ BASH_VERSINFO -ge 6 || BASH_VERSINFO -eq 5 && BASH_VERSINFO -ge 2
On Fri, Apr 2, 2021 at 2:56 AM Chet Ramey wrote:
>
> On 4/1/21 2:55 PM, konsolebox wrote:
>
> > So to keep compatibility, would this be the right way?
> >
> > if [[ BASH_VERSINFO -ge 6 || BASH_VERSINFO -eq 5 && BASH_VERSINFO -ge 2 ]];
> > then
> > unset() {
> > set --
i still vote for same syntax to unset as setting it, makes only sense
On Wed, Mar 31, 2021, 01:05 konsolebox wrote:
> On Tue, Mar 16, 2021 at 8:12 AM Chet Ramey wrote:
> > This means that, given the following script,
> >
> > declare -A a
> > key='$(echo foo)'
> > a[$key]=1
> > a['$key']=2
> >
On Tue, Mar 16, 2021 at 8:12 AM Chet Ramey wrote:
> This means that, given the following script,
>
> declare -A a
> key='$(echo foo)'
> a[$key]=1
> a['$key']=2
> a["foo"]=3
>
> # never worked
> unset -v a[$key]
> declare -p a
>
> # unsets element with key $key
> unset -v a['$key']
> declare -p a
On 3/29/21 8:07 PM, Marco Ippolito wrote:
Examples are more for the texinfo documentation; the man page is big
enough already.
What goes in the man page Vs in the texinfo documentation, please?
It's a rough convention. The man page is more for a technical description
of bash and its
> Examples are more for the texinfo documentation; the man page is big
> enough already.
What goes in the man page Vs in the texinfo documentation, please?
On 3/15/21 9:41 PM, Koichi Murase wrote:
2021年3月16日(火) 8:12 Chet Ramey :
key='x],b[$(echo uname >&2)'
(( assoc[$key]++ ))
[...]
declare -A assoc=(["x],b[\$(echo uname >&2)"]="1" )
I agree with this change. I think the same rule should apply also to
the indexed arrays in the arithmetic
On 3/16/21 8:34 AM, Greg Wooledge wrote:
I would not complain if unset became a shell keyword
I'm not considering this.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.edu
On 3/15/21 9:03 PM, Léa Gris wrote:
zsh also provide a nice feature to iterate both keys and values in a single
loop:
for key value in "${(kv)assoc_array}"; do
printf '%s -> %s\n' "$key" "$value"
done
I don't have any current interest in implementing the zsh mini-language for
expansion
On 3/15/21 8:32 PM, L A Walsh wrote:
That said, I'd want to see those examples in the manpage.
FWIW -- I seem to remember that the manpage could use some more
simple examples in a few places.
Examples are more for the texinfo documentation; the man page is big
enough already.
--
``The
wheres the sense of not having same var format rules as.. normal, but not
for unset ?
i can do arr[$key]= without problems, cool, why bug around big in unset
( aka choose keywords instead of lower for, ... important functionality )
On Wed, Mar 17, 2021 at 5:05 PM Jesse Hathaway
wrote:
> I
I would welcome this change, I struggled today with trying to
increment an associative array
in an arithmetic context. I think this change would make for much
better ergonomics when
working with associative arrays. Yours kindly, Jesse Hathaway
Date:Wed, 17 Mar 2021 08:28:26 +0100
From:Alex fxmbsw7 Ratchev
Message-ID:
| you write like when word splitting no use double quotes
| sure but as far as i understood:
| key='$( faulty_command )'
| unset -v assoc["$key"]
| would still get expanded
you write like when word splitting no use double quotes
sure but as far as i understood:
key='$( faulty_command )'
unset -v assoc["$key"]
would still get expanded
i cant get friendly'ed to builtins being over keywords
much more to say but i cant, greets tho
On Wed, Mar 17, 2021 at 4:46 AM
Date:Tue, 16 Mar 2021 13:26:30 +0100
From:Alex fxmbsw7 Ratchev
Message-ID:
| no idea about your internal rules of keyword and builtin but clearly its
| gotta parse it at most 1. level otherwise its big security fault isnt it
No, it isn't. No more than
as for shell keyword be more important and vital to shells, than more
external [or so?] built ins
unset -v var ## very internal to shell var extension thatss not possible to
disable
[[ .. ## a test for strings or so containing
..
it would not make sense to have unset be lower than [[
On Tue, Mar
i guess shell-keyword all then :))
On Tue, Mar 16, 2021 at 1:37 PM Greg Wooledge wrote:
> On Tue, Mar 16, 2021 at 01:26:30PM +0100, Alex fxmbsw7 Ratchev wrote:
> > no idea about your internal rules of keyword and builtin
>
> unicorn:~$ type [
> [ is a shell builtin
> unicorn:~$ type [[
> [[ is
On Tue, Mar 16, 2021 at 01:26:30PM +0100, Alex fxmbsw7 Ratchev wrote:
> no idea about your internal rules of keyword and builtin
unicorn:~$ type [
[ is a shell builtin
unicorn:~$ type [[
[[ is a shell keyword
You know how you're allowed to omit quotes inside [[ but not inside [ ?
That's because
no idea about your internal rules of keyword and builtin but clearly its
gotta parse it at most 1. level otherwise its big security fault isnt it
its a shell fuctionality keyword, unset, so ..
On Tue, Mar 16, 2021 at 1:21 PM Greg Wooledge wrote:
> On Tue, Mar 16, 2021 at 09:24:01AM +0100, Alex
On Tue, Mar 16, 2021 at 09:24:01AM +0100, Alex fxmbsw7 Ratchev wrote:
> it doesnt make me much sense that unset -v assoc[$key] gives syntax error
> or so..
Think of it this way: what would happen if you had a filename in a
variable -- say, $file -- and you ran this command:
rm -f $file
You'd
hello, excuse my bad english
your sample code that you write what it should produce you propose for the
future so ?
it doesnt make me much sense that unset -v assoc[$key] gives syntax error
or so..
also about the assoc_expand_once i dont understand
cant it be as written, expand_once ( maybe
> On Mar 15, 2021, at 9:03 PM, Léa Gris wrote:
>
> Please excuse my profanity of mentioning zsh in this list, but I really think
> features and behavior convergence can benefit end users in multiple ways,
> especially when expanding beyond the POSIX sh scope.
>
> What direction has taken zsh
2021年3月16日(火) 8:12 Chet Ramey :
> key='x],b[$(echo uname >&2)'
> (( assoc[$key]++ ))
> [...]
> declare -A assoc=(["x],b[\$(echo uname >&2)"]="1" )
I agree with this change. I think the same rule should apply also to
the indexed arrays in the arithmetic command. With `index='0],b[1';
Le 16/03/2021 à 01:12, Chet Ramey écrivait :
What do folks think?
Please excuse my profanity of mentioning zsh in this list, but I really
think features and behavior convergence can benefit end users in
multiple ways, especially when expanding beyond the POSIX sh scope.
What direction has
On 2021/03/15 17:12, Chet Ramey wrote:
I'm kicking around a change
This means that, given the following script,
declare -A a
key='$(echo foo)'
a[$key]=1
a['$key']=2
a["foo"]=3
What do folks think?
---
Looks like a flexible way to deal with some of the side effects
of the
I'm kicking around a change to associative array subscript expansion that
would basically force the equivalent of `assoc_expand_once' on all the
time, with additional changes to prevent unwanted double expansion in an
arithmetic expression context. The option would still exist, and still be
81 matches
Mail list logo
