On 2021/10/30 09:07, Robert Elz wrote:
oguzismailuy...@gmail.com said:
| `break' is not a keyword in the shell, but a special command.
That's true. However, 99%**1 of script writers don't see
it that way,g they believe it is just like "if" or
"while" or "done" or "return".
That's why
On 2021-10-30 at 23:07 +0700, Robert Elz wrote:
> For people who don't believe that all programming languages should work
> the same way (usually the same way as the one they learned first) this
> isn't necessarily as important - but that's a tiny majority of people.
Uh? That's a quite different s
On 2021-10-29 at 22:41 -0700, L A Walsh wrote:
> > This is quite unfair.
> Huh? It's true--look at how functions have to be stored in
> the environment because someone was able to hack "their
> own system" where they already have unrestricted shell access.
>
> If that isn't ugly or lame, what i
On Sat, Oct 30, 2021 at 08:45:05PM +0300, Oğuz wrote:
> I know, it's great. Though I still couldn't figure out how to have a
> command run on login and it drives me mad.
Depends on *how* you log in.
On 10/29/21 6:06 PM, Roger Morris wrote:
Bash Version: 5.0
Patch Level: 17
Release Status: release
Description:
I believe there's a bug in bash 4.4 (and still in 5.1) that wasn't
there in 4.3.30
When 'command -p' runs, it no longer seems to restore the hash to its
previous value.
This came i
On Sat, Oct 30, 2021 at 7:07 PM Robert Elz wrote:
>
> What POSIX says about this (which you probably know already) is:
>
> A loop shall enclose a break or continue command if the loop
> lexically encloses the command. A loop lexically encloses a
> break or continue command
On Sat, Oct 30, 2021 at 6:55 PM Chet Ramey wrote:
> You might be interested in
>
> https://www.austingroupbugs.net/view.php?id=842
The only argument against dynamic scoping there is that one might use
`break 1000' for exiting the outermost lexically enclosing loop and I
don't think anyone does th
What POSIX says about this (which you probably know already) is:
A loop shall enclose a break or continue command if the loop
lexically encloses the command. A loop lexically encloses a
break or continue command if the command is:
[and just paraphrasing the conditions]
On 10/30/21 11:02 AM, Oğuz wrote:
On Sat, Oct 30, 2021 at 4:50 PM Greg Wooledge wrote:
As Chet said, it's counterintuitive. Most people don't expect function A
to be able to affect loops inside function B.
I do, and a subshell can prevent function A from affecting loops
inside function B. Bu
such stuff could be with aliases maybe accomplished, not sure of your req's
On Sat, Oct 30, 2021, 17:03 Oğuz wrote:
> On Sat, Oct 30, 2021 at 4:50 PM Greg Wooledge wrote:
> > As Chet said, it's counterintuitive. Most people don't expect function A
> > to be able to affect loops inside function
On Sat, Oct 30, 2021 at 4:50 PM Greg Wooledge wrote:
> As Chet said, it's counterintuitive. Most people don't expect function A
> to be able to affect loops inside function B.
I do, and a subshell can prevent function A from affecting loops
inside function B. But that is not a real problem, you
On Sat, Oct 30, 2021 at 02:39:19PM +0300, Oğuz wrote:
> I found that this behavior had been introduced in 2014, with the
> following commit message:
>
> > set loop_level to 0
> > when entering a function so break and continue in functions don't
> > break loops running outside of the function. Fix
I would expect the following to print only 1 and return,
f() { break; }
for x in 1 2 3; do
echo $x
f
done
because `f' is called from within a loop, and executed in the same
environment as the loop. But it doesn't. It prints all 1, 2, and 3;
and complains about `break'
Le 30/10/2021 à 07:41, L A Walsh écrivait :
On 2021/10/29 12:33, Greg Wooledge wrote:
On Fri, Oct 29, 2021 at 11:59:02AM -0700, L A Walsh wrote:
How much lameness Chet has introduced into bash to accommodate
the wrong users.
This is quite unfair.
Huh? It's true--look at how functions hav
14 matches
Mail list logo
