On 10/14/23 12:03 PM, Robert Elz wrote:
However in the case of a special built-in utility (which "." is) then
the requirements are much stricter:
� If the command name is a special built-in utility, variable assignments
shall affect the current execution environment before the utility
On 10/15/23 12:31 AM, Martin D Kealey wrote:
On Sun, 15 Oct 2023, 03:15 Ti Strga, wrote:
I think I would attack this from an entirely different angle: what about
simply modifying Baeh so that it slurps in the entire file upon opening it?
Bash reads up to 8K at a time, minus bookkeeping
On 10/15/23 12:24 AM, Martin D Kealey wrote:
On Sun, 15 Oct 2023, 03:05 Greg Wooledge, wrote:
On Sat, Oct 14, 2023 at 12:55:21PM -0400, Ti Strga wrote:
it's just the "[[ -v foo ]]" tests to see where along the cloning
process we are.
*Shudder*
Likewise, b.
If the *real* goal is to
On 10/14/23 12:46 AM, Martin D Kealey wrote:
Respectfully I must disagree.
This aspect of Bash's behaviour has a very long historical precedent.
Back when I used the Bourne Shell we didn't have `local`, so we used to
write `var= func` to make sure that `func` couldn't mess with *our* `var`.
On Sun, 15 Oct 2023, 02:03 Robert Elz, wrote:
> Date:Sat, 14 Oct 2023 14:46:12 +1000
> From:Martin D Kealey
> Message-ID: a2+3nnknhm5a+...@mail.gmail.com>
>
>
> | Back when I used the Bourne Shell we didn't have `local`, so we used to
> | write `var= func` to
On Sun, 15 Oct 2023, 03:15 Ti Strga, wrote:
> On Fri, Oct 13, 2023 at 5:59 PM Grisha Levit
> wrote:
> > IMHO you'd be better off just putting a `{` line at the start and `}`
> line at the end of your scripts
>
The big weakness of the "{}" approach is that if a writer forgets to do
> that,
On Sun, 15 Oct 2023, 03:05 Greg Wooledge, wrote:
> On Sat, Oct 14, 2023 at 12:55:21PM -0400, Ti Strga wrote:
> > it's just the "[[ -v foo ]]" tests to see where along the cloning
> process we are.
>
> *Shudder*
>
Likewise, b.
If the *real* goal is to overwrite a running script with a new
On Fri, Oct 13, 2023 at 5:59 PM Grisha Levit wrote:
> On Fri, Oct 13, 2023, 10:03 Ti Strga wrote:
>>
>> [*] Alternatively, there's the trick about putting the entire script
>> contents inside a compound statement to force the parser to read it all,
>> but that just makes the script harder for a
On Sat, Oct 14, 2023 at 12:55:21PM -0400, Ti Strga wrote:
> it's just the "[[ -v
> foo ]]" tests to see where along the cloning process we are.
*Shudder*
I foresee so much more pain in your future. Seriously, this is going
to blow up in your face at some point. -v peeks into some incredibly
On Fri, Oct 13, 2023 at 5:35 PM Chet Ramey wrote:
> This is what happens. First, you have to remember that variables supplied
> as temporary assignments to builtins like eval and source persist for the
> entire life of that builtin's execution, and appear in the environment of
> child processes
Date:Sat, 14 Oct 2023 14:46:12 +1000
From:Martin D Kealey
Message-ID:
| Back when I used the Bourne Shell we didn't have `local`, so we used to
| write `var= func` to make sure that `func` couldn't mess with *our* `var`.
If you were using the original Bourne
On Sat, 14 Oct 2023 at 06:33, Robert Elz wrote:
> The issue we have (which possibly might be similar in bash, but only
> possibly - but it would explain the symptoms) is that when one does
>
> VAR=value command
>
> "VAR" is essentially made a local variable for command, so its value
> in
On Fri, 13 Oct 2023 13:02:30 -0400
Ti Strga wrote:
> First off, I have a feeling that GMail is going to garble the line
> wrapping in this message; I cannot get it to stop being "helpful".
> Apologies if that happens.
>
> I've encountered some behavior that I cannot find described anywhere in
>
On Fri, Oct 13, 2023, 10:03 Ti Strga wrote:
> [*] Alternatively, there's the trick about putting the entire script
> contents inside a compound statement to force the parser to read it all,
> but that just makes the script harder for a human to read. Copy-and-exec
> makes the top-level scripts
On 10/13/23 1:02 PM, Ti Strga wrote:
First off, I have a feeling that GMail is going to garble the line
wrapping in this message; I cannot get it to stop being "helpful".
Apologies if that happens.
I've encountered some behavior that I cannot find described anywhere in
the man page, and I'm
Date:Fri, 13 Oct 2023 14:21:59 -0400
From:"Dale R. Worley"
Message-ID: <87bkd2idrs@hobgoblin.ariadne.com>
| but I coded an instance of
| your description (above), and it does not show the dubious behavior that
| you report.
Your test isn't accomplishing
On Fri, Oct 13, 2023 at 02:21:59PM -0400, Dale R. Worley wrote:
> I was too lazy to chew through your example, but I coded an instance of
> your description (above), and it does not show the dubious behavior that
> you report. Specifically,
>
> $ bash -version
> GNU bash, version
On Fri, Oct 13, 2023 at 2:22 PM Dale R. Worley wrote:
> $ bash -version
> GNU bash, version 5.1.0(1)-release (x86_64-redhat-linux-gnu)
If I can get 5.1.x installed, I'll try with that; if the behavior is no longer
exhibited then it's possible something got wonky between then and
5.2.15.
Ti Strga writes:
> The summary is that if a parameter is set specifically for a '.'/'source'
> command, and the source'd file calls 'exec' to run another script, then
> that exec'd script cannot unset the parameter; if we want that parameter
> to not be present in the exec'd script, then the
First off, I have a feeling that GMail is going to garble the line
wrapping in this message; I cannot get it to stop being "helpful".
Apologies if that happens.
I've encountered some behavior that I cannot find described anywhere in
the man page, and I'm hoping to learn whether it's a bug (it
20 matches
Mail list logo
