Frédéric Harper

We added a while ago a `kubefirst civo quota` command, but it's not automated. We should add this to the pre-flight checks. At some point the Civo API wasn't returning...

So it's implemented already, it's just that the CLI still display the `tails` command instead of the `kubefirst logs` one when starting the creation process with another cloud than k3d.

Thanks for feature request @aemadrid Just to be sure I understand correctly, cause it seems to be conflicting messaging here. > I'd like to be able to onboard a running...

@mwoodpatrick: thanks for reporting this issue. I can replicate this, but I have no idea why we would modify stty settings, so let me check with the engineering team.

@fharper no sorry, the team is quite swamped at the moment, and didn't have time to investigate to find what is changing stty.

@mwoodpatrick can you try this PR? https://github.com/kubefirst/kubefirst/pull/2184 I'm struggling to test on my machine for another reason right now.

@fharper: let me try it again tomorrow. @mwoodpatrick: did you fix your other issue? If so, can you try this PR also please?

I was able to test it on macOS, using the script you created @CristhianF7 and the PR didn't fix it for me. Here is the differences: ``` < gfmt1:cflag=4b00:iflag=6b02:lflag=200005cf:oflag=3:discard=f:dsusp=19:eof=4:eol=ff:eol2=ff:erase=7f:intr=3:kill=15:lnext=16:min=1:quit=1c:reprint=12:start=11:status=14:stop=13:susp=1a:time=0:werase=17:ispeed=38400:ospeed=38400 ---...

Another use has this issue with ZSH on Fedora Linux.

I thought it was shell-specific since I'm also on ZSH, but @CristhianF7 who can't replicate the issue is also using the same shell.