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
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
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
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'' -
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
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
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
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'
> >
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
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.
[My apologies up front for the length of this email. The short story is I
played around with the multi-coproc support: the fd closing seems to work
fine to prevent deadlock, but I found one bug apparently introduced with
multi-coproc support, and one other coproc bug that is not new.]
On
Ok. Then this is what I was able to make of it. To be honest, I prefer the
Makefile syntax over the script syntax, because of its direct substitutions.
Other improvements that anyone likes to suggest? Is this the best bash can
do?
On Thu, Mar 14, 2024 at 3:47 AM Martin D Kealey
wrote:
> On
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
18 matches
Mail list logo
