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
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
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
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
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.
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
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
22 matches
Mail list logo
