Date:Wed, 07 Apr 2021 22:24:27 -0400
From:wor...@alum.mit.edu (Dale R. Worley)
Message-ID: <87a6q9ikdg@hobgoblin.ariadne.com>
| "The documentation is the contract between the user and
| the implementer." If something undocumented happens to work, there is
|
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. Yo
Comming back on this 10month old thread...
On Tue, Jun 30, 2020 at 12:30:53PM -0400, Chet Ramey wrote:
> On 6/28/20 9:49 AM, felix wrote:
>
> > Bash Versions: 3.2.57(1)-release, 5.0.3(1)-release, 5.1.0(1)-alpha
> >
> > In order to reduce forks and make some tasks a lot quicker, I run
> > forked
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 curre
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 necessary
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 the
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 s
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 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 ta
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 wo
This is a topic I originally mentioned in another discussion on the
new treatment of assoc_expand_once (
https://lists.gnu.org/archive/html/bug-bash/2021-03/msg00059.html ).
As in the mail subject, I suggest supporting empty keys for
associative arrays. Does anyone have any opinion on this suggest
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 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
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 an
Le 08/04/2021 à 20:30, felix écrivait :
You could have a look:
https://f-hauri.ch/vrac/mandelbrot_backgndBc.sh.txt
https://f-hauri.ch/vrac/mandelbrot_backgndBc_4macOs.sh.txt
Have a look at my POSIX/shell version that is even slightly faster:
https://gist.github.com/leagris/59e1b7e7246202
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.)
It
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 09, 2021 at 01:23:09AM +0200, Léa Gris wrote:
> > You could have a look:
> >https://f-hauri.ch/vrac/mandelbrot_backgndBc.sh.txt
> >https://f-hauri.ch/vrac/mandelbrot_backgndBc_4macOs.sh.txt
> Have a look at my POSIX/shell version that is even slightly faster:
> https://gist.git
18 matches
Mail list logo
