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 :-)
[Documentation] Parameter expansion: missing colon in example
Hello,
The example on parameter expansion[1] should perhaps read :
$ echo ${v:-unset}
instead of :
$ echo ${v-unset}
Yes ? More context:
---8<---
${parameter:-word}
If parameter is unset or null, the expansion of word is substituted. Otherwise,
the value of parameter is substituted.
$ v=123
$ echo ${v-unset}
123
--->8---
Thanks !
--
1.
https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html
Re: git amend commit with backticks on cli causes tty to crash
On Fri, Jul 21, 2023 at 9:14 AM Dale R. Worley wrote: > (...) > Also, you don't state explicitly what you think the error is. I assume > you mean that "Press [ctrl-d] again and tab (tty 5) crashes." should not > be happening. > > But it looks to me like you're sending ctrl-d into a shell. That, of > course, is EOF, and usually tells the shell to exit. If it's a login > shell, the whole login session ends. One thing that comes to mind is that there was a behavior change in 5.2 around how EOF is handled while the parser is looking for a matching quote. For example, with Bash 5.1 (note: indicates pressing the Return key in the prompt) bash-5.1# echo ' > bash: unexpected EOF while looking for matching `'' bash: syntax error: unexpected end of file bash-5.1# GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-musl) And Bash 5.2 bash-5.2# GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-musl) bash-5.2# echo ' > bash: unexpected EOF while looking for matching `'' > exit In 5.1, when you input a command that has an unpaired quote and then input Ctrl-d you get a syntax error and return to the primary prompt. When you do the same in 5.2, the first Ctrl-d will show an unexpected EOF message but you will remain in the secondary prompt. A second Ctrl-d will then cause Bash to exit. This change was discussed in https://mail.gnu.org/archive/html/bug-bash/2023-02/msg00145.html
Re: git amend commit with backticks on cli causes tty to crash
Wiley Young writes: > I'm seeing this behavior on Fedora 38. Possibly it's just some user error > again, since i'm figuring out how to use vim and git at a slightly above > novice level. :-) Well, I think I can get an idea of what you're doing. I'm not sure, you really want to create a "minimal example" without all the surrounding bric-a-brac. Particularly, there seems to be some sort of framework, perhaps "LiveUsb1", through which both the commands and responses are filtered, which makes it really hard to track what is doing what. Also, why is there the stuff about vim? Also, you don't state explicitly what you think the error is. I assume you mean that "Press [ctrl-d] again and tab (tty 5) crashes." should not be happening. But it looks to me like you're sending ctrl-d into a shell. That, of course, is EOF, and usually tells the shell to exit. If it's a login shell, the whole login session ends. Now I don't know how pts's are managed, but they are "pseudo ttys" and I wouldn't be surprised if, when a login session on a pts ends, the pts of that session is deleted. My Fedora 34 seems to create and delete pts's as needed. Dale
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 ..
>
