Re: problem anomalies , possibly aliases related
On Thu, Jul 20, 2023 at 3:28 PM Greg Wooledge wrote: > > The idea that this would "work" is quite surprising to me. The basic > idea of a function is that it does stuff and then returns you to the > point where you were when the function was called. > > Really ? > In other languages, would you expect that you might call a function, > and have that function reach upward through the call stack and manipulate > your control flow? To name a few :-) In C longjmp() lands you anywhere on the the call path. Any try/catch language will do it too In C family there are even function that never return (see noreturn function attribute) FORTRAN alternate return is fun too. Not counting assembly where you can land anywhere with a ret *reg Basically this is hacker day to day job to return anywhere unexpected :-)
Re: problem anomalies , possibly aliases related
On Fri, 21 Jul 2023, 04:09 Greg Wooledge, wrote: > On Fri, Jul 21, 2023 at 12:33:07AM +1000, Martin D Kealey wrote: > > Saying that this *ought* to be done using aliases is not reasonable, as > it > > means forgoing the other stuff that functions can do, like taking > > parameters, declaring local variables, or returning a status. > > Well in any case, the behavior you wanted is not reliable […] even across > versions of bash. > Well sure, it's not reliable NOW but it worked for 20+ years before the change in 4.4. Since I now need to use a work around for versions 4.4 through 5.2 there's little point in pushing for reinstatement, and that's not really my point. Rather, I'm making the point that features I (and likely others) depend on seem to keep getting arbitrarily broken. This is an appeal to anyone looking at the next bug report and thinking "this behaviour is obviously unneeded": before you make a PR to kill it, please dream more about potential uses and users. -Martin >
Re: problem anomalies , possibly aliases related
On Fri, Jul 21, 2023, 1:36 PM Greg Wooledge wrote: > On Fri, Jul 21, 2023 at 01:15:16PM +0200, alex xmb ratchev wrote: > > On Thu, Jul 20, 2023, 8:09 PM Greg Wooledge wrote: > > > On Fri, Jul 21, 2023 at 12:33:07AM +1000, Martin D Kealey wrote: > [...] > > > Well in any case, the behavior you wanted is not reliable across > shells, > > > nor even across versions of bash. > > > > > > > me ? > > I was replying to Martin Kealey. "You" in that sentence referred to him. > ah k , thxx > i dont have interest in supporting not newest versions ... 4.4 ? uh > > not my case , nor would i support it > > The "non-local break/continue" that Martin wanted doesn't work in 5.2 > either. > > > > > unicorn:~$ bash-4.4 foo > > > 1 > > > f > > > foo: line 1: break: only meaningful in a `for', `while', or `until' > loop > > > 2 > > > f > > > foo: line 1: break: only meaningful in a `for', `while', or `until' > loop > > > 3 > > > f > > > foo: line 1: break: only meaningful in a `for', `while', or `until' > loop > > unicorn:~$ bash-5.2 foo > 1 > f > foo: line 1: break: only meaningful in a `for', `while', or `until' loop > 2 > f > foo: line 1: break: only meaningful in a `for', `while', or `until' loop > 3 > f > foo: line 1: break: only meaningful in a `for', `while', or `until' loop > > > I used 4.3 and 4.4 in my demonstration because that was where the > behavior changed. Everything *before* 4.3 presumably works like 4.3, > and everything *after* 4.4 presumably works like 4.4, though I didn't > test all the versions. Only a tiny handful. > > I showed exactly how I ran my demonstration, so you could have repeated > it using your own bash version to see whether it supported the non-local > break/continue. > > But I guess now you don't have to, since I just did it for you. > cool =)) >
Re: problem anomalies , possibly aliases related
On Fri, Jul 21, 2023 at 01:15:16PM +0200, alex xmb ratchev wrote: > On Thu, Jul 20, 2023, 8:09 PM Greg Wooledge wrote: > > On Fri, Jul 21, 2023 at 12:33:07AM +1000, Martin D Kealey wrote: [...] > > Well in any case, the behavior you wanted is not reliable across shells, > > nor even across versions of bash. > > > > me ? I was replying to Martin Kealey. "You" in that sentence referred to him. > i dont have interest in supporting not newest versions ... 4.4 ? uh > not my case , nor would i support it The "non-local break/continue" that Martin wanted doesn't work in 5.2 either. > > unicorn:~$ bash-4.4 foo > > 1 > > f > > foo: line 1: break: only meaningful in a `for', `while', or `until' loop > > 2 > > f > > foo: line 1: break: only meaningful in a `for', `while', or `until' loop > > 3 > > f > > foo: line 1: break: only meaningful in a `for', `while', or `until' loop unicorn:~$ bash-5.2 foo 1 f foo: line 1: break: only meaningful in a `for', `while', or `until' loop 2 f foo: line 1: break: only meaningful in a `for', `while', or `until' loop 3 f foo: line 1: break: only meaningful in a `for', `while', or `until' loop I used 4.3 and 4.4 in my demonstration because that was where the behavior changed. Everything *before* 4.3 presumably works like 4.3, and everything *after* 4.4 presumably works like 4.4, though I didn't test all the versions. Only a tiny handful. I showed exactly how I ran my demonstration, so you could have repeated it using your own bash version to see whether it supported the non-local break/continue. But I guess now you don't have to, since I just did it for you.
Re: problem anomalies , possibly aliases related
On Thu, Jul 20, 2023, 8:09 PM Greg Wooledge wrote:
> On Fri, Jul 21, 2023 at 12:33:07AM +1000, Martin D Kealey wrote:
> > C has longjmp, and other languages have exceptions. Non-local break is a
> > usable "Bash shaped" analogue of those. Not perfect, sure, but close
> enough
> > to be useful. (Non-local continue is a logical extension of that.)
> >
> > Saying that this *ought* to be done using aliases is not reasonable, as
> it
> > means forgoing the other stuff that functions can do, like taking
> > parameters, declaring local variables, or returning a status.
>
> Well in any case, the behavior you wanted is not reliable across shells,
> nor even across versions of bash.
>
me ? i dont have interest in supporting not newest versions ... 4.4 ? uh
not my case , nor would i support it
unicorn:~$ cat foo
> f() { echo f; break; }
>
> for i in 1 2 3; do
> echo "$i"
> f
> done
> unicorn:~$ bash-4.3 foo
> 1
> f
> unicorn:~$ bash-4.4 foo
> 1
> f
> foo: line 1: break: only meaningful in a `for', `while', or `until' loop
> 2
> f
> foo: line 1: break: only meaningful in a `for', `while', or `until' loop
> 3
> f
> foo: line 1: break: only meaningful in a `for', `while', or `until' loop
> unicorn:~$ dash foo
> 1
> f
> 2
> f
> 3
> f
> unicorn:~$ ksh foo
> 1
> f
> 2
> f
> 3
> f
>
>
> Since it's not possible to do it this way portably, I suggest that the
> alias alternative would be the way to go.
>
aliases .. simple text replacements ..
>
Re: problem anomalies , possibly aliases related
On Fri, Jul 21, 2023 at 12:33:07AM +1000, Martin D Kealey wrote:
> C has longjmp, and other languages have exceptions. Non-local break is a
> usable "Bash shaped" analogue of those. Not perfect, sure, but close enough
> to be useful. (Non-local continue is a logical extension of that.)
>
> Saying that this *ought* to be done using aliases is not reasonable, as it
> means forgoing the other stuff that functions can do, like taking
> parameters, declaring local variables, or returning a status.
Well in any case, the behavior you wanted is not reliable across shells,
nor even across versions of bash.
unicorn:~$ cat foo
f() { echo f; break; }
for i in 1 2 3; do
echo "$i"
f
done
unicorn:~$ bash-4.3 foo
1
f
unicorn:~$ bash-4.4 foo
1
f
foo: line 1: break: only meaningful in a `for', `while', or `until' loop
2
f
foo: line 1: break: only meaningful in a `for', `while', or `until' loop
3
f
foo: line 1: break: only meaningful in a `for', `while', or `until' loop
unicorn:~$ dash foo
1
f
2
f
3
f
unicorn:~$ ksh foo
1
f
2
f
3
f
Since it's not possible to do it this way portably, I suggest that the
alias alternative would be the way to go.
Re: problem anomalies , possibly aliases related
i most dont understand your text story
On Thu, Jul 20, 2023, 3:03 PM Martin D Kealey
wrote:
>
>
> On Thu, 20 Jul 2023, 18:03 Grisha Levit, wrote:
>
>> Sounds like you want all the commands in the alias to be executed as a
>> group -- so you can just write it as one:
>>
>> alias bad='{ echo fail; continue; }'
>>
>
> That right there USED to work as a function:
>
> bad() { echo fail; continue; }
>
ah cont in func
But then someone suggested allowing non-local break & continue was a bug,
> and the few people who considered it couldn't think of even as simple an
> example as that right there.
>
> So it was "fixed", and now that function doesn't work. It sickens me that
> the work-around is to enable alias expansion in scripts.
>
> *Grumble*
> -Martin
>
> PS: and people think I'm crazy for wanting to write new stuff in Perl, in
> preference to Bash. Bash as a language has nothing else going for it, so if
> after 28 years I still can't consider it stable, what is the point?
>
perl is simple and big .. i like
old around y2k when i tried hack some perl together
the public media , as many else , is every thing than perfect
perl i didnt see fpr years , as many other tho big links
about 28 years , u can see it as 1) specification
or 2) version
i just wanna say .. it still takes a while
>
Re: problem anomalies , possibly aliases related
On Thu, 20 Jul 2023, 23:28 Greg Wooledge, wrote: > The idea that this would "work" is quite surprising to me. Shell functions are SO unlike functions in other languages that it surprises me that anyone would assume any particular parallel holds. Everything about them is dynamic: where they find variables (up frame by default unless you use "local"); even their very existence, which only begins when the flow of control passes over their definitions, and ends with unset -f. So when one reads the manual and it says "outer loop", there is no reason to assume this is referring to grammatical scope; dynamic scope makes just as much sense, and a quick test confirms it. Well, it DID confirm it. The basic idea of a function is that it does stuff and then returns you to > the point where you were when the function was called. > Except that it's not (at least, not since we mangled the mathematical word "function" to mean what we used to call "subroutine"). C has longjmp, and other languages have exceptions. Non-local break is a usable "Bash shaped" analogue of those. Not perfect, sure, but close enough to be useful. (Non-local continue is a logical extension of that.) Saying that this *ought* to be done using aliases is not reasonable, as it means forgoing the other stuff that functions can do, like taking parameters, declaring local variables, or returning a status. -Martin
Re: problem anomalies , possibly aliases related
On Thu, Jul 20, 2023 at 11:03:35PM +1000, Martin D Kealey wrote:
> On Thu, 20 Jul 2023, 18:03 Grisha Levit, wrote:
>
> > Sounds like you want all the commands in the alias to be executed as a
> > group -- so you can just write it as one:
> >
> > alias bad='{ echo fail; continue; }'
> >
>
> That right there USED to work as a function:
>
> bad() { echo fail; continue; }
>
> But then someone suggested allowing non-local break & continue was a bug,
> and the few people who considered it couldn't think of even as simple an
> example as that right there.
>
> So it was "fixed", and now that function doesn't work. It sickens me that
> the work-around is to enable alias expansion in scripts.
>
> *Grumble*
The idea that this would "work" is quite surprising to me. The basic
idea of a function is that it does stuff and then returns you to the
point where you were when the function was called.
In other languages, would you expect that you might call a function,
and have that function reach upward through the call stack and manipulate
your control flow? Some languages might have features designed for
that (Tcl's "uplevel" command comes to mind), but these are exceptions,
and experienced programmers would use such features sparingly.
What you're really looking for is the behavior of a macro, rather than
a function. C has macros (#define), and so does bash (alias).
So, if this is the behavior you want, then do what xmb is doing. Turn
on alias expansions, and write your flow-controlling macros as aliases.
Use functions for the things that should work normally (no control flow
modifications or parser short-circuiting), and aliases for the weird,
quirky behaviors that wouldn't normally be allowed.
Re: problem anomalies , possibly aliases related
On Thu, 20 Jul 2023, 18:03 Grisha Levit, wrote:
> Sounds like you want all the commands in the alias to be executed as a
> group -- so you can just write it as one:
>
> alias bad='{ echo fail; continue; }'
>
That right there USED to work as a function:
bad() { echo fail; continue; }
But then someone suggested allowing non-local break & continue was a bug,
and the few people who considered it couldn't think of even as simple an
example as that right there.
So it was "fixed", and now that function doesn't work. It sickens me that
the work-around is to enable alias expansion in scripts.
*Grumble*
-Martin
PS: and people think I'm crazy for wanting to write new stuff in Perl, in
preference to Bash. Bash as a language has nothing else going for it, so if
after 28 years I still can't consider it stable, what is the point?
>
Re: problem anomalies , possibly aliases related
the bugfixed version
that ran 24m long
On Thu, Jul 20, 2023, 10:08 AM alex xmb ratchev wrote:
>
>
> On Thu, Jul 20, 2023, 10:03 AM Grisha Levit wrote:
>
>>
>>
>> On Thu, Jul 20, 2023, 01:42 alex xmb ratchev wrote:
>>
>>>
>>>
>>> 2. it says [[ ! -d then ' continue ' .. where is cp
>>> i call no , not c , ...
>>> 1. cp missing
>>> 2. the [[ ! -d return to continue looks bug wrong
>>>
>>
>> Try putting the code that uses the alias into a function, and then print
>> the function definition. You'll see how it's being expanded.
>>
>> Using Martin's example:
>>
>> $ alias A='B ; C'
>> $ f() { D && A; }
>> $ declare -p -f f
>> f ()
>> {
>> D && B;
>> C
>> }
>>
>> Sounds like you want all the commands in the alias to be executed as a
>> group -- so you can just write it as one:
>>
>> alias bad='{ echo fail; continue; }'
>>
>
> alias bad .. :)) ... ye that s my only fix to it
> else id use funcs , but i see.only slowdown using those
> esp. when i cant cont or break a loop
>
> ill have , i hope , a ( selfcoded ) httpd again
> full of public domain open sources codes , of me , and doc texts regarding
> 0 - 100 debian bash gawk
>
> i urge , whoever runs such sites , to update them to the ( users ) current
> knowledge
>
> i find 100% of the google res inet useless untrue outdated , money monkey
> written .. wrong
>
> greets
>
>>
db3.2bash
Description: Binary data
Re: problem anomalies , possibly aliases related
On Thu, Jul 20, 2023, 10:03 AM Grisha Levit wrote:
>
>
> On Thu, Jul 20, 2023, 01:42 alex xmb ratchev wrote:
>
>>
>>
>> 2. it says [[ ! -d then ' continue ' .. where is cp
>> i call no , not c , ...
>> 1. cp missing
>> 2. the [[ ! -d return to continue looks bug wrong
>>
>
> Try putting the code that uses the alias into a function, and then print
> the function definition. You'll see how it's being expanded.
>
> Using Martin's example:
>
> $ alias A='B ; C'
> $ f() { D && A; }
> $ declare -p -f f
> f ()
> {
> D && B;
> C
> }
>
> Sounds like you want all the commands in the alias to be executed as a
> group -- so you can just write it as one:
>
> alias bad='{ echo fail; continue; }'
>
alias bad .. :)) ... ye that s my only fix to it
else id use funcs , but i see.only slowdown using those
esp. when i cant cont or break a loop
ill have , i hope , a ( selfcoded ) httpd again
full of public domain open sources codes , of me , and doc texts regarding
0 - 100 debian bash gawk
i urge , whoever runs such sites , to update them to the ( users ) current
knowledge
i find 100% of the google res inet useless untrue outdated , money monkey
written .. wrong
greets
>
Re: problem anomalies , possibly aliases related
On Thu, Jul 20, 2023, 01:42 alex xmb ratchev wrote:
>
>
> 2. it says [[ ! -d then ' continue ' .. where is cp
> i call no , not c , ...
> 1. cp missing
> 2. the [[ ! -d return to continue looks bug wrong
>
Try putting the code that uses the alias into a function, and then print
the function definition. You'll see how it's being expanded.
Using Martin's example:
$ alias A='B ; C'
$ f() { D && A; }
$ declare -p -f f
f ()
{
D && B;
C
}
Sounds like you want all the commands in the alias to be executed as a
group -- so you can just write it as one:
alias bad='{ echo fail; continue; }'
>
Re: problem anomalies , possibly aliases related
sorry for possible negative effected texting
i d wish to discuss , why aliases are a big gain , and why so my indenting
i ve been in #bash and #awk since 200[012] , where such negative english
texting like me getting banned there for years , ..
i did learn back then , and did , and do answer bash awk q s with top code
( to my subjective level )
many of my res es was marked as 'impossible' or 'shitty old sh like
workaround' , by .. uhm whoever
later then went unfriendly and so i quit the , english wrong chat
.. i understand here may be not the place for such a discussion , whenever
u wanted to join .. i just .. began mentioning it here
u know a place to post pro tech topics ? or smth ?
On Thu, Jul 20, 2023, 8:22 AM Martin D Kealey
wrote:
> Hi Alex
>
> Aliases are not functions, and they don't work the same way.
>
> A function is like a separate script, except that it runs in the same
> process & context as the caller. Its meaning is determined as the script
> RUNS.
> An alias is quite different: it replaces tokens while the script is being
> PARSED.
>
do u know , that is around the big process where the bash determines when
thers errs in the file to exec an err msg and fail to run
In particular,
> alias A='B ; C'
> D && A
> will replace `A` with `B ; C` to get `D && B ; C` which is THEN parsed
> into the equivalent of:
> { D && B ; } ; C
>
> (Same if you use a line break instead of a semicolon.)
>
a yes my detail thinking error , already the ~third time in my time
thank u much bout pointing this out
.. i .. thought .. aliases are text replacements
what i didnt know is .. whats a bit obvious .. bash replaces em when read ,
not just in [[ $? 0 , but completly regardless of the code
.. then makes sense that there continue .. my bug
The output of `set -x` reflects the structure of the code, not the literal
> text. We expect it to exclude comments, extra blank lines, and names of
> aliases where they are used.
>
> Unless you actually need to modify how a script is PARSED, don't use
> aliases; use functions instead.
>
im an old tech style veteran , aliases are there to be learned
noone could still force me to use limited ( due to wrong / outdated rules )
instead unlimited
i mean , u say , like many else , aliases arent to be used
is that cause many fails ?
its pure braindamage
alike the sayings 'bash is no programming language' many times and tho just
from a few users
i contered it the same way .. bs nonsense
-Martin
>
> PS: please use structure-indicative indentation when showing examples.
>
ah oh my spacing ( since i dont tab )
i did that since long for long
now , same as i thought back then about ur tabbing finding it cool
its a massive non maintainable desaster
and as i thought cool , my ' cool ' about my current style
cmds=0spaces
[[ cond ]] && {
cmd1
cmd2
}
for i in bla ; do
[[ foo ]] &&
a ||
b
done
cmds no space
no op / conditional +1 space
id call it reverse tabbing , or some other texting
its the delight
have to think 0.1% about wtf id indent ( not happily with it ) on old style
ill todo a better text description , and positive sides of it
greets
>
Re: problem anomalies , possibly aliases related
Hi Alex
Aliases are not functions, and they don't work the same way.
A function is like a separate script, except that it runs in the same
process & context as the caller. Its meaning is determined as the script
RUNS.
An alias is quite different: it replaces tokens while the script is being
PARSED.
In particular,
alias A='B ; C'
D && A
will replace `A` with `B ; C` to get `D && B ; C` which is THEN parsed into
the equivalent of:
{ D && B ; } ; C
(Same if you use a line break instead of a semicolon.)
The output of `set -x` reflects the structure of the code, not the literal
text. We expect it to exclude comments, extra blank lines, and names of
aliases where they are used.
Unless you actually need to modify how a script is PARSED, don't use
aliases; use functions instead.
-Martin
PS: please use structure-indicative indentation when showing examples.
