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
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 3/2/20 2:54 PM, Keith Thompson wrote:
> From: kst
> To: bug-bash@gnu.org
> Subject: echo vs /bin/echo appears to affect variable scope
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Comp
On Mon, Mar 02, 2020 at 11:54:24AM -0800, Keith Thompson wrote:
> /bin/echo hello \
> > BASH_BUG_TEST_$((i++))_$word
The redirection happens in the subshell that was created to run the
external command.
From: kst
To: bug-bash@gnu.org
Subject: echo vs /bin/echo appears to affect variable scope
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linux bomb20
On 11/2/12 10:48 AM, Nikolai Kondrashov wrote:
> Hi everyone,
>
> I've encountered a very strange behavior regarding variable scope and traps,
> which looks very much like a bug.
This will be fixed, to the extent that identical blocks of code like the
two below will do the s
Hi everyone,
I've encountered a very strange behavior regarding variable scope and traps,
which looks very much like a bug.
This command:
echo '
set -e;
tt() { declare -r v=; };t() { tt; };
ff() { declare -r v=; false; }; f() { ff; };
trap t EXIT;
Antonio Macchi wrote:
> $ a=OUTSIDE
>
> $ f1 () { local a=INSIDE; f2; }
>
> $ f2 () { echo "before: $a";
> unset a;
> echo "after: $a"; }
>
>
> $ f3 () { local a=INSIDE;
> echo "before: $a";
> unset a;
> echo "after: $a"; }
>
>
> $ f1
> before
$ a=OUTSIDE
$ f1 () { local a=INSIDE; f2; }
$ f2 () { echo "before: $a";
unset a;
echo "after: $a"; }
$ f3 () { local a=INSIDE;
echo "before: $a";
unset a;
echo "after: $a"; }
$ f1
before: INSIDE
after: OUTSIDE
$ f3
before: INSIDE
after:
I
29 matches
Mail list logo
