On Tue, Mar 19, 2024 at 02:24:34PM -0400, Chet Ramey wrote:
> On 3/19/24 11:50 AM, Mike Jonkmans wrote:
>
> > > Yes. There is one thing missing: the transformation should expand to a
> > > `declare' command when applied to a local variable at the current scope,
> > > even if there are no attribute
On 3/19/24 11:50 AM, Mike Jonkmans wrote:
Yes. There is one thing missing: the transformation should expand to a
`declare' command when applied to a local variable at the current scope,
even if there are no attributes to be displayed. Agreed?
I am less convinced about outputting a `-g' for a gl
On Mon, Mar 18, 2024 at 04:19:55PM -0400, Chet Ramey wrote:
> On 3/14/24 8:57 PM, Zachary Santer wrote:
> > On Thu, Mar 14, 2024 at 3:43 PM Chet Ramey wrote:
> > >
> > > In fact, before 2020, local -p with no name arguments behaved the same as
> > > local without arguments, which just printed all
On 3/14/24 8:57 PM, Zachary Santer wrote:
On Thu, Mar 14, 2024 at 3:43 PM Chet Ramey wrote:
In fact, before 2020, local -p with no name arguments behaved the same as
local without arguments, which just printed all the local variable names at
the current scope in the form of assignment statemen
On Thu, Mar 14, 2024 at 3:43 PM Chet Ramey wrote:
>
> In fact, before 2020, local -p with no name arguments behaved the same as
> local without arguments, which just printed all the local variable names at
> the current scope in the form of assignment statements. That was certainly
> not usable to
On 3/14/24 11:47 AM, Zachary Santer wrote:
On Thu, Mar 14, 2024 at 11:09 AM Chet Ramey wrote:
`local' always operates at the current function scope. `local -p' only
displays local variables that exist at the current function scope.
Oh shoot. I hadn't considered that 'local -p' and 'declare -
On Thu, Mar 14, 2024, 15:16 Zachary Santer wrote:
> On Thu, Mar 14, 2024 at 9:54 AM Greg Wooledge wrote:
> >
> > I don't quite understand what this is saying. Do the variables have
> > different names, or the same name? If they have different names, then
> > the nameref shouldn't "hide" the ot
On Thu, Mar 14, 2024 at 11:47 AM Zachary Santer wrote:
>
> Kind of funny that 'local -g' seems to work just fine, doing the same
> thing as 'declare -g' (at least in bash 4.2), but whatever.
bash 5.2.15 as well.
On Thu, Mar 14, 2024 at 11:09 AM Chet Ramey wrote:
>
> `local' always operates at the current function scope. `local -p' only
> displays local variables that exist at the current function scope.
Oh shoot. I hadn't considered that 'local -p' and 'declare -p' would
do different things.
Kind of fun
On 3/14/24 10:15 AM, Zachary Santer wrote:
Not on a machine with bash right now. 'declare -p var_3' in func_2 ()
said var_3 was not found,
You didn't use `declare -p' in func_2.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippo
On 3/14/24 8:29 AM, Zachary Santer wrote:
Alright, that's all fair. But this?
On Sun, Mar 10, 2024 at 7:29 PM Zachary Santer wrote:
Additionally, a nameref variable referencing a variable declared in a calling
function hides that variable in the scope of the function where the nameref
vari
On Thu, Mar 14, 2024 at 10:47 AM Greg Wooledge wrote:
>
> I can't seem to duplicate this. This is with bash 5.2:
Run the whole script from my original email. Maybe I managed to trip
bash up with something I edited out of the last email. Pay particular
attention to var_3.
#!/usr/bin/env bash
fu
Date:Thu, 14 Mar 2024 09:53:37 -0400
From:Greg Wooledge
Message-ID:
| I don't quite understand what this is saying.
It was a weird attempt to explain the behaviour bel9w
| Do the variables have different names, or the same name?
Depends which vars you mean but
On Thu, Mar 14, 2024 at 10:15:35AM -0400, Zachary Santer wrote:
> > $ cat ./nameref-what
> > #!/usr/bin/env bash
> >
> > func_1 () {
> > local var_3='EGG'
> > func_2
> > printf '%s\n' "func_1:"
> > local -p var_3
> > }
> >
> > func_2 () {
> > local -n nameref_3='var_3'
> > nameref_3='so
On Thu, Mar 14, 2024 at 9:54 AM Greg Wooledge wrote:
>
> I don't quite understand what this is saying. Do the variables have
> different names, or the same name? If they have different names, then
> the nameref shouldn't "hide" the other variable. But they can't have
> the same name, because a
On Thu, Mar 14, 2024 at 08:29:47AM -0400, Zachary Santer wrote:
> Alright, that's all fair. But this?
>
> On Sun, Mar 10, 2024 at 7:29 PM Zachary Santer wrote:
> >
> > Additionally, a nameref variable referencing a variable declared in a
> > calling function hides that variable in the scope of t
On Wed, Mar 13, 2024 at 3:44 PM Chet Ramey wrote:
>
> `local' always creates variables at the current scope, or at the global
> scope if `-g' is supplied. If it's supplied the name of a nameref, it first
> resolves the nameref to find the name of the variable it's supposed to act
> on, failing if
On Thu, Mar 14, 2024, 12:08 Greg Wooledge wrote:
> On Thu, Mar 14, 2024 at 08:27:33AM +0100, alex xmb sw ratchev wrote:
> > how to unset a nameref
>
> Look at "help unset". Specifically the -n option.
>
thxx++
>
On Thu, Mar 14, 2024 at 08:27:33AM +0100, alex xmb sw ratchev wrote:
> how to unset a nameref
Look at "help unset". Specifically the -n option.
how to unset a nameref
On Wed, Mar 13, 2024, 20:44 Chet Ramey wrote:
> On 3/10/24 7:29 PM, Zachary Santer wrote:
>
> > Bash Version: 5.2
> > Patch Level: 26
> > Release Status: release
> >
> > Description:
> >
> > On Sun, Mar 10, 2024 at 3:55 PM Zachary Santer
> wrote:
> >>
> >> Relatedly, how
On 3/10/24 7:29 PM, Zachary Santer wrote:
Bash Version: 5.2
Patch Level: 26
Release Status: release
Description:
On Sun, Mar 10, 2024 at 3:55 PM Zachary Santer wrote:
Relatedly, how would one set attributes on a variable declared in a
calling function? 'readonly' and 'export' can do it for
On Mon, 11 Mar 2024 11:45:17 -0400
Chet Ramey wrote:
> On 3/11/24 12:08 AM, Kerin Millar wrote:
>
> > Speaking of which, to do both of these things has some interesting effects
> > ...
> >
> > $ z() { local -g a; unset -v a; a=123; echo "innermost: $a"; }; unset -v a;
> > x; declare -p a
> >
On 3/10/24 3:55 PM, Zachary Santer wrote:
Relatedly, how would one set attributes on a variable declared in a
calling function? 'readonly' and 'export' can do it for their
respective attributes, but otherwise, I think you just can't.
You can't (you might be able to using nameref tricks I'm not
On 3/11/24 12:08 AM, Kerin Millar wrote:
Speaking of which, to do both of these things has some interesting effects ...
$ z() { local -g a; unset -v a; a=123; echo "innermost: $a"; }; unset -v a; x;
declare -p a
innermost: 123
inner: 123
outer: 123
declare -- a
$ z() { local -g a; unset -v a;
On 3/11/24 8:26 AM, Adrian Ho wrote:
Thanks much for all the insights, everyone! Indeed, the man page isn't
clear on how to reason about `local -g`. I'm now left with the following
understanding:
1. There is *nothing local* about `local -g`; it operates entirely at the
global level.
It exists
Thanks much for all the insights, everyone! Indeed, the man page isn't
clear on how to reason about `local -g`. I'm now left with the following
understanding:
1. There is *nothing local* about `local -g`; it operates entirely at the
global level. In particular, it does *not* create a local referen
On Sun, 10 Mar 2024 17:36:13 -0400
Greg Wooledge wrote:
> On Sun, Mar 10, 2024 at 04:01:10PM -0400, Lawrence Velázquez wrote:
> > Basically, without an assignment, "local -g" does nothing.
>
> Well, the original purpose of -g was to create variables, especially
> associative arrays, at the globa
On Sun, 10 Mar 2024 16:01:10 -0400
Lawrence Velázquez wrote:
> On Sun, Mar 10, 2024, at 1:51 PM, Kerin Millar wrote:
> > Dynamic scoping can be tremendously confusing. The following examples
> > should help to clarify the present state of affairs.
> >
> > $ x() { local a; y; echo "outer: $a"; }
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: msys
Compiler: gcc
Compilation CFLAGS: -march=nocona -msahf -mtune=generic -O2 -pipe
-D_STATIC_BUILD
uname output: MINGW64_NT-10.0-19045 Zack2021HPPavilion 3.4.10.x86_64
2024-02-10 08:39 UTC x86_64 Msys
Machine
On Sun, Mar 10, 2024 at 06:39:19PM -0400, Lawrence Velázquez wrote:
> On Sun, Mar 10, 2024, at 5:36 PM, Greg Wooledge wrote:
> > Here it is in action. "local -g" (or "declare -g") without an assignment
> > in the same command definitely does things.
> >
> > hobbit:~$ f() { declare -g var; var=in_f
On Sun, Mar 10, 2024, at 5:36 PM, Greg Wooledge wrote:
> Here it is in action. "local -g" (or "declare -g") without an assignment
> in the same command definitely does things.
>
> hobbit:~$ f() { declare -g var; var=in_f; }
> hobbit:~$ unset -v var; f; declare -p var
> declare -- var="in_f"
This
On Sun, Mar 10, 2024 at 04:01:10PM -0400, Lawrence Velázquez wrote:
> Basically, without an assignment, "local -g" does nothing.
Well, the original purpose of -g was to create variables, especially
associative arrays, at the global scope from inside a function.
I think this thread has been asking
On Sun, Mar 10, 2024, at 1:51 PM, Kerin Millar wrote:
> Dynamic scoping can be tremendously confusing. The following examples
> should help to clarify the present state of affairs.
>
> $ x() { local a; y; echo "outer: $a"; }
> $ y() { local a; a=123; echo "inner: $a"; }
> $ x; echo "outermost: $a"
On Sun, Mar 10, 2024 at 1:51 PM Kerin Millar wrote:
> $ y() { local -g a; a=123; echo "inner: $a"; }
> $ x; echo "outermost: $a"
> inner: 123
> outer: 123
> outermost:
>
> This may not be. There, the effect of the -g option effectively ends at the
> outermost scope in which the variable, a, was d
On Sun, 10 Mar 2024 23:09:37 +0800
Adrian Ho wrote:
> [Apologies, an earlier edition of this bug report was sent from the address
> a...@lex.03s.net, which can only be replied to from my internal network.
> Please ignore that report. Thanks much!]
>
> Configuration Information [Automatically gen
[Apologies, an earlier edition of this bug report was sent from the address
a...@lex.03s.net, which can only be replied to from my internal network.
Please ignore that report. Thanks much!]
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc-11
Compilation CFLAGS: -DSSH_SOURCE_BASHRC
uname output: Linux lex 6.5.0-25-generic #25-Ubuntu SMP PREEMPT_DYNAMIC Wed Feb
7 14:58:39 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Machine Typ
37 matches
Mail list logo
