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.